m.invoke() vs. m()

[Reinier Zwitserloot]

inline.



> > Code should remain generally parsable and resolvable [snip
>
> Agreed, but I'm not sure how that affects this discussion.
>
>
I explained why making closure variables act differently affects parsability
and resolvability. If the namespace of a field or variable depends on its
type, then a parsing problem with its type causes more problems than it does
now.


> > Problem #3:
> > It would also lead to problems with private API.
>
> Not with the rule I mentioned above.
>
>
Yes, it still does, even if closure-typed fields are in a special namespace.


> > Problem #4:
> > Method Resolution is already one of the most complicated aspects of java,
> > and you're suggesting that we make it even more complicated.
>
> Again, I'm not suggesting we do so.


You may not have suggested it, but you were defending it. Whether you are an
active supporter or merely on the fence but defending it, this is an
excellent argument against convoluting method namespaces even more, and I
haven't heard any serious retort of this particular issue. An issue that has
also been raised repeatedly and for example the java7 BOF at devoxx. (That
is, method resolution in general being very complex, not specifically about
how this syntax meshes with that).


>
> No, I would deliberately make this knowable without knowing the types,
> lest we get into exponential memory/time to resolve types.
>
>
How? If all fields occupy this new namespace, then javac7 is no longer
capable of compiling code that would compile just fine on javac6, which is
not an option.

 --Reinier Zwitserloot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091207/61ca2860/attachment.html