Hi Neal,<br><br><div class="gmail_quote">2009/12/7 Neal Gafter <span dir="ltr">&lt;<a href="mailto:neal@gafter.com">neal@gafter.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Mon, Dec 7, 2009 at 2:46 PM, Osvaldo Doederlein <span dir="ltr">&lt;<a href="mailto:opinali@gmail.com" target="_blank">opinali@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


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.</blockquote></div><div><br>
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&#39;s worth doing, but it&#39;s not trivial.<br>


<br></div></div>
</blockquote></div><br>I&#39;m aware of these issues, that&#39;s why I wrote &quot;see&quot; not &quot;contain&quot;. 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&#39;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&#39;t care about implementation complexity, compiler writers are born to suffer :-) as long as the end-user&#39;s features/complexity tradeoff (if any) is ok. And everything I&#39;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.<br>
<br>(*) 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&#39;s hover to know.) I don&#39;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&#39;t possibly make it even remotely bad enough to make me not want transparent closure calls.<br>
<br>A+<br>Osvaldo<br>