The Artima Developer Community
Sponsored Link

Weblogs Forum
Inner Classes or Closures

38 replies on 3 pages. Most recent reply: Apr 16, 2007 8:34 PM by Howard Lovatt

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 38 replies on 3 pages [ « | 1 2 3 ]
Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Seriously, right now, go read a compilers book... Posted: Oct 18, 2006 10:56 PM
Reply to this message Reply
Advertisement
> PS To Carson re. static method: I have used a static
> method rather than a member because I think it unlikely
> that anyone will want to change the collection classes;
> but if you want to write your own collection classes that
> expand on the standard ones and add methods as members
> then you can easily do it.

The proliferation of Util's and Helpers and Factories in java is a Very, Very Bad Thing. It indicates that Something Is Really F**king Broken. OO programming means, among other things, associating data with the operations over that data. With modern IDE's and intellisense, not associating the two is a murderous blow to discoverability.

> PPS To Carson re. why braces used: A comma is used to
> separate variable declarations in the same statement as
> well as argument lists, hence you need something to
> delimit the end of the closure other than a comma. In the
> above I have used braces.

No. You don't. You simply don't. You are thinking about it as a linear scan rather than a recursive grammar. Here is the BNF (not left factored), for the last time:


closure -> '\' arg_list -> closure_body
arg_list -> nil | arg | arg ',' arg_list
closure_body -> expr | '{' statement_list '}'


Hell, I'll even throw in method dispatch:


method_call -> identifier '(' expression_list ')'
expression_list -> nil | expr | expr ',' expression_list


You don't have to write "myMethod(myArg;, mySecondArg;)" when you call a method normally, so why on earth should you be forced to do so simply because closures waddle onto the scene? Because they have a scary name? They are JUST EXPRESSIONS.

This is bush league parsing guys. Even a moron like me can do it.

Cheers,
Carson

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Inner Classes or Closures Posted: Oct 19, 2006 12:06 AM
Reply to this message Reply
Howard,

Call me old fashioned, but if I'm looping I expect a FOR or a DO. :-)


Carson

I'm with you on too many helpers and factories being a bad thing.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Seriously, right now, go read a compilers book... Posted: Oct 19, 2006 1:12 AM
Reply to this message Reply
Carson,

> The proliferation of Util's and Helpers and Factories in
> java is a Very, Very Bad Thing. It indicates that
> Something Is Really F**king Broken. OO programming means,
> among other things, associating data with the operations
> over that data. With modern IDE's and intellisense, not
> associating the two is a murderous blow to
> discoverability.

Whether they (JCP) choose to write a new collections library that has member functions is a separate issue to closure and inner classes; so I will put that issue aside in the interests of separating concerns and stick with assuming that they wont.

> You don't have to write "myMethod(myArg;, mySecondArg;)"
> when you call a method normally, so why on earth should
> you be forced to do so simply because closures waddle onto
> the scene? Because they have a scary name? They are JUST
> EXPRESSIONS.

There are omissions in your grammar, in particular it is not true that both a closure and a method call can have an expression only in their lists. A closure can have any statement (it does not have to be an expression - it can for example be a declaration, an if statement, etc.). Take a look at the example below that has only one comma and one semicolon - it won't parse with a context free grammar and I think that it won't parse satisfactorily even including context.
    method \x -> Type name, name2;

Note that the closure declares a local variable called name and that the syntax for variable declarations includes a comma separated list of variable names. In particular:
    Type name, name2;

Declares two local variables of type Type, one called name and the other called name2. Also note that the declaration above is exactly the same as the end of the faulty method with closure call. Therefore the parser cannot tell whether the method has two argument or if the closure has two local variables. I suggested braces to resolve the problem, i.e.:
    method {\x -> Type name, name2}; // One argument, two locals
    method {\x -> Type name}, name2; // Two arguments, one local

This difficulty does not arise with method calls since variables cannot be declared in argument lists of methods, unlike statement lists of closures.

You could postulate that single statement closures cannot declare locals, but I still think that the expression will be confusing and difficult to parse, e.g.:
    method \x -> if ( booleanExpression ) Type name, name2; // One or two arguments, one or two locals?

The writing of a parsable grammar is much more difficult than you are implying with your simple examples. Real grammars are very complicated, take a look at the Java language specification.

PS Since you are getting angry, capitals in posts, I won't post again on this discussion about parsing - feel free to have the last word.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Seriously, right now, go read a compilers book... Posted: Oct 19, 2006 11:55 AM
Reply to this message Reply
> The proliferation of Util's and Helpers and Factories in
> java is a Very, Very Bad Thing. It indicates that
> Something Is Really F**king Broken. OO programming means,
> among other things, associating data with the operations
> over that data. With modern IDE's and intellisense, not
> associating the two is a murderous blow to
> discoverability.

A little more intelligence in the IDE and perhaps some annotations could revive the discoverability.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Evolutionary Dead End Posted: Oct 19, 2006 12:31 PM
Reply to this message Reply
>A little more intelligence in the IDE and perhaps some annotations could revive the discoverability.

I'm really sick of the argument "You just need better tools".

No, what we really need is a better language. Tools support is a crutch. Crutches are for the lame.

A little more forethought would go a long way towards eliminating the lameness.

Java the platform was set in stone at version 1.1. There have been no interesting changes to the runtime since then - its all done with compiler tricks and the truth is that the language is clearly unable to evolve because too much of it is hardwired into the VM at the wrong level of abstraction.

Living languages are fully implemented in themselves and thus open for modification by casual programmers to address new requirements.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Seriously, right now, go read a compilers book... Posted: Oct 19, 2006 12:49 PM
Reply to this message Reply
> There are omissions in your grammar, in particular it is not true that both a closure and a method call can have an expression only in their lists.

Exactly.


Type name, name2;


is a statement list, not an expression, which is why you would have to write:


\x -> {Type name1, name2; ...}


rather than


\x -> Type name1, name2


or, in your other example


method \x -> { if ( booleanExpression ) Type name, name2; }


> Real grammars are very complicated

I disagree. Obviously the BNF I'm throwing up is simplified, but the real grammar wouldn't be hugely more complicated.

> I won't post again on this discussion about parsing - feel free to have the last word.

I don't want the last word. I want *you* to have the last word, which should be:

"Oooooh, I get it. I guess we don't have to make java syntactically insane to support closures in a natural way."

<smile/>

BTW, I can't claim to be the originator of this syntax. It's a mix of Haskell and C# 3.0. Download the C# 3.0 spec at

http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.doc

and take a look at section 26.3.
Note, in particular, the last entry in the BNF snippets they give:

lambda-expression-body -> expression | block

I'm *pretty* sure that if Microsoft can make it work, Sun can too.

Cheers,
Carson

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: Evolutionary Dead End Posted: Oct 19, 2006 1:06 PM
Reply to this message Reply
> >A little more intelligence in the IDE and perhaps some
> annotations could revive the discoverability.
>
> I'm really sick of the argument "You just need better
> tools".
>
> No, what we really need is a better language. Tools
> support is a crutch. Crutches are for the lame.

I'd like to evolve the language too, but I also recognise that this can be painful. Thus the large bias in favour of modest changes with good backward compatibility is quite understandable. I want my old code to keep working, I want to continue using 3rd party code that isn't going to be updated in a hurry.
Then there is the matter of only making changes which can attract general agreement, which (currently) precludes such things as operator overloading.
Is there a way out of this dilemma?

For now we have to make do with what is possible. Crutches can make that a little happier.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Inner Classes or Closures Posted: Oct 31, 2006 9:42 AM
Reply to this message Reply
> > Maybe you are still suffering from generics
> indigestion!
>
> Very true.

Having looked at the various proposals (elsewhere on this forum) for extending the language; it seems to me that they all suffer from the inability to handle Java's implementation of generics in an easily readable form.

I don't think that the fault necessarily lies with the new changes proposed. Java's generics notation has been like throwing a ball of mud into a river, tainting everything downstream and rendering even the simplest structures opaque.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Inner Classes or Closures Posted: Apr 16, 2007 8:34 PM
Reply to this message Reply
I have blogged another comparison of the different inner class/closure proposals at:

http://www.artima.com/weblogs/viewpost.jsp?thread=202004

Flat View: This topic has 38 replies on 3 pages [ « | 1  2  3 ]
Topic: Inner Classes or Closures Previous Topic   Next Topic Topic: A First Look at Apollo


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us