m.invoke() vs. m()

[Vladimir Kirichenko]

Reinier Zwitserloot wrote:
> Allowing m() instead of m.invoke() actually spends quite a bit of the
> user-facing complexity budget. I've gone over the reasons, but just to
> highlight the ones relevant to user-facing complexity:
> 
>  - Changing the type of a field from closure to non-closure or vice
> versa can change the resolution in other source files, and in your own
> source file. In all java releases so far, the only way to do that is to
> actually add or remove members, or rename them.

Which causes compilation error. So where is the problem? And in what way
that change will not cause same thing with invoke?

>  - Any form of identifiers(args); is already extremely complicated, and
> ".invoke"-less closure invocation is adding more to it. This isn't just
> a complexity cost carried by those implementing method resolution. IDEs
> are a big help here (as they can unambiguously show you what such an
> expression resolves to), but that doesn't eliminate the user-facing
> complexity completely. Those helpful IDEs are also going to have more
> work cut out for them to make this resolution work. 

Adopting generics made a lot of work in IDEs. In compare with this
change it's a significantly bigger work. Or annotations! This strange
things introduced to java causes a lot of pain in IDE developers asses. So?

> Java has been around
> for decades, the IDEs for a long time too, and yet, resoluton in files
> with syntax errors is STILL a big issue. 

Let's stop world from moving forward before we bring java IDE's to level
what they could read our minds.

> Java isn't scala. 

And yet there are IDEs for scala!

> You and I may be familiar with this notion, but the number of java
programmers who are familiar with java is tiny.

I'm sorry but your arguments have no realistic base at all. Noone was
familiar with C# before it was made. Now look at the market. Closures is
a basic thing. There is nothing new. If java stop moving forward it will
be dead in couple of years. Do not think that java language is state of
the art. Everything changes. Once it was COBOL. Then remember delphi
which "allowed to write windows programs without knowing that complex
stuff". Where are they now? Java is conceptually pretty old now. It have
the only choice now - moving forward or, slowly yes, but digging in.

-- 
Best Regards,
Vladimir Kirichenko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091208/17b88d5b/attachment.bin