> 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:

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.

> 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.:

> 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.

>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.

> >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.

> > 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.