Wow, this thread blew up in my face. I try to get some consensus going
that at this point any closure proposal beats no closures at all, and
the thread spins out into yet another CICE v. BGGA snipefest.
Ugh. You'd almost think sun was right to let these dogs lie for now
and move on to other things.
I still say there's a way to marry BGGA and CICE together.
Other than syntax, which I really hope nobody gets hung up about too
much, there are two big differences between CICE and BGGA:
1. BGGA has structural types. You could have a List of (int, int =>
double)s, in BGGA. The idea of a function that takes 2 ints and
produces a double is itself just as much a type as a "String" or an
"InputStream". In all the other ones, you don't get these. Instead you
have to create an interface with 1 method in it.
2. BGGA has 'long returns' - the ability to break out of a closure
AND out of the codeblock that CONTAINED the closure. So, inside the
closure part of, say, a foreach loop done as a library call, you could
return out of the entire method that contained your code. This is
clearly important if you want to write language extensions as plain
jane java API methods: The closures should be so transparant that the
meaning of 'continue', 'break', and 'return' do not change. They
certainly don't change in a foreach block or a while block, so why
should they change in a someFileObject.feedLinesThroughClosure([String
=> void] { /* do stuff with each line */ } block?
If you've ever heard an argument about why BGGA is better than CICE,
its usually focused around #2: By making 'break', 'continue', and
'return' transparent, BGGA can easily be used to build something like
the foreach loop, or the ARM proposal, as just a library method. After
all, if you have a foreach loop, 'return' doesn't somehow return out
of the for method - it returns out of whatever method contains the for
each loop. BGGA works like this as well, but in CICE, a closure
automatically means that break, continue, and return 'reset'. That's
not good if you want to add things like ARM, or adding the counter
into foreach loops, or map for each. I know, I know - it's a
complicated beast and you can probably write a whole new java puzzlers
based just on long returns alone, but clearly there's real value here.
On the other hand, arguments CICErs use against BGGA are usually
focused on either the syntax, or a generic "It's too complicated", or
complaints that structural types aren't "java-esque". I hardly ever
hear CICErs complain specifically that long returns are bad - if it
comes up at all, its that its too complex to be worth it.
So, if you take CICE, but make the CICE syntax be return/break/
continue transparent (this would entail making a way to return out of
the closure instead of out of the containing method somehow), and add
easy syntax to fit a delegate into a SAM if the signatures match (some
sort of autoboxing, basically), how many people in the FCM, CICE, and
BGGA camps are still of the opinion that they'd rather have no
closures at all than this proposal?
There has got to be some middle ground here.
On Jan 13, 4:53 am, Chris Adamson <[email protected]> wrote:
> On Jan 12, 10:40 am, Reinier Zwitserloot <[email protected]> wrote:
>
> > I don't care which of the many closure proposals is adapted. As long
> > as one is.
>
> This seemed to be Dick's point (well, part of it, along with the idea
> of shortening release cycles so that changes don't have the angst of
> "if we don't get it in now, we have to wait three more years"). But I
> think pining for the closures supporters to pull behind one proposal
> or another ignores the political realities of what's going on. The
> reason there's a stalemate is that the vocal part of the Java
> community is roughly split into thirds, if what I'm seeing from polls
> and forums is any indication:
>
> * one third want BGGA
> * one third want a closure proposal other than BGGA (e.g., FCM or
> CICE)
> * one third don't want Java closures at all
>
> Clearly, the third camp won't ally itself with either of the first
> two, and among the two closure camps, BGGA doesn't seem strong enough
> to force the issue over the objections of 2/3 of the Java community
> (the FCM/CICE camp plus the "no closures" camp). Many of the FCM/CICE
> supporters seem unwilling to switch to BGGA, preferring no closures to
> a proposal they dislike.
>
> None of the factions represents even a majority, nor does there appear
> any prospect for two of the factions to unite and trump the third,
> unless you'd care to argue that the "no BGGA" and "no closures" camps
> have inadvertently collaborated and won for now by keeping the lead
> proposal, BGGA, out of Java 7.
>
> --Chris
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
