There won't be a problem with either this, or CICE, or any other proposal that does NOT include structural typing (a.k.a. method types a.k.a. functional types a.k.a. anything else which boils down to listing input and output types instead of being forced to give operations a name).
For example, this thing will reduce an anonymous inner class version of something like Comparator, into a one-liner. It doesn't add any new types, and Comparator can easily be public (in fact, it IS public - and it was designed well before any of the closure proposals). On the other hand, structural typing-based closure proposals (including BGGA and FCM, though FCM isn't quite as married to the idea of having structural types in the first place, and the current FCM prototype in fact doesn't actually have them, they are in FCM's spec only so far), do have this interop problem. However, as BGGA has taken the lead on this, the solution is fairly simple: All prototypes that come out with structural typing should use the BGGA prototype class space for building these things. Either way, interop with non-closure- enabled java is meh. Unless you like implementing FunctionIIBD<String, String, Void, Nothing>. However, even in these cases, there are (at least in the case of both BGGA and FCM) rules about how closures should fold themselves into 'SAM's (Single-Abstract-Method types, the basis of non-structurally typed closure proposals like CICE). SAMs are fully backwards, forwards, sidewards, upwards, and downwards compatible with anything and everything out there. NB: Heading off (or inviting?) closure flames: I think structural types are a bad idea, at least for java. I think closures are a fantastic idea. On Feb 5, 4:46 am, Christian Catchpole <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
