Yeah I get that. But say a closure is implemented as an interface with a method called 'closure', but someone else's implementation is a class with one method, who cares what it's called.
I'm assuming this matters not at all because the code which defines the closure is the one which ends up calling it. I just flagging the possibility that it might cause problems that there is no 'real' closure definition. On Feb 5, 1:38 pm, Michael Neale <[email protected]> wrote: > Oh the thing is it doesn't change the source AT ALL - its purely > visual code folding. So you open it up in emacs, it will look like > normal java etc... (in fact they would have the feature probably > turned off by default). > > I repeat this does NOT change the source code. Its still the same > inner classes etc. > > Christian Catchpole wrote: > > My first (and hopefully for your sake, last) question is.. > > > Regardless of how neat and cool any such implementation can be, do we > > loose the benefit of a standard "interoperability". Or is the purpose > > of closures that the implementation is private? Does it matter in > > practice? > > > On Feb 5, 11:04 am, Michael Neale <[email protected]> wrote: > > > Thought people may be interested in > > > this:http://code.google.com/p/lambda4jdt/ > > > > and this:http://www.jetbrains.net/jira/browse/IDEADEV-34469 > > > > (not sure if netbeans is thinking of the same). > > > > Thoughts? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
