|
|
Re: Seriously, right now, go read a compilers book...
|
Posted: Oct 18, 2006 10:12 PM
|
|
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.
|
|
Previous Topic
