m.invoke() vs. m()

[Osvaldo Doederlein]

Hi Neal,

2009/12/7 Neal Gafter <neal at gafter.com>

> On Mon, Dec 7, 2009 at 2:46 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:
>
>> The problem of separate variable/method namespaces can be handled by
>> making the conflict illegal - any given scope cannot see two methods, or
>> variables of closure type, with the same signature.
>
>
> Things are not that simple.  What about nested scopes, or the scope of a
> class/interface versus its subclasses/subinterfaces?  Hiding?  Shadowing?
> Overloading?  These all have to be worked out.  I think it's worth doing,
> but it's not trivial.
>
>
I'm aware of these issues, that's why I wrote "see" not "contain". But we
already have all the complexity of considering such issues to resolve
variable and method references. I surely believe that adding transparent
closure calls to the mix may create some additional questions that don't
have a single, trivial and obvious answer. Perhaps somebody could illustrate
the problem with some sketch of grammar changes or some other way. As mostly
a language user (*) I don't care about implementation complexity, compiler
writers are born to suffer :-) as long as the end-user's features/complexity
tradeoff (if any) is ok. And everything I've read from this thread failed to
convince me that transparent calls will turn Java into the next C++ monster
or even 1% of that.

(*) Ten years ago I implemented a reasonably complete reverse engineering
tool, that would consume both Java sources and classfiles, building an UML
metamodel enriched with partial understanding of method bodies. I still
remember that type resolution was surprisingly hard due to all combinations
of imports, nesting, inner classes etc. But the lesson learned for me today,
is that implementation != usage; as a Java language user, I _never_ thought
of type resolution as anything even _minimally_ complex. (Context alone is
usually sufficient to disambiguate things even without the help from IDEs;
for the classic example, List can be either a collection or a AWT control
but I never have to look at the imports or the editor's hover to know.) I
don't know how well this experience maps to the admittedly more complex case
of method resolution with closures, but my gut feeling is that the current
complexity is very small and adding closures can't possibly make it even
remotely bad enough to make me not want transparent closure calls.

A+
Osvaldo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091207/4320e6d2/attachment.html