As you rightfully pointed out, a closure is more or less a referenceable and
callable code block. At the moment, the closest relative that exists in Java
is the anonymous inner class:
Collections.sort(myList, new Comparator<String>() {
public int compare(String s1, String s2) {
return s1.length() - s2.length();
}});
At first glance, it doesn't seem that different than one of the closure
approaches (forgive me if I'm mangling syntax):
Collections.sort(myList, {String s1, String s2 => return s1.length() -
s2.length; });
And indeed, one of the suggested implementations would simply consist of syntax
sugar that recognizes use of single-method interfaces and convert the latter
into the former at compile time. I know how to type pretty well and I don't
really mind a few extra keystrokes.
The real difference comes about when one wants to do flow control: returns,
breaks, exception handling. Syntax sugar solution that doesn't extend go
beyond what we can do now with anonymous inner classes doesn't solve these
problems. The infamous for-as-a-library example:
// this could be simulated with anon inner classes
myList.for({item => System.out.println(item);});
// but there's no way to do this except with... exceptions (ugly IMO)
blah = ...;
myList.for({item => if(item.equals(blah)) return true; });
There's similar issues with variable scope. Currently, anonymous inner classes
can see variables declared in enclosing scope, but only if they're declared
final. It's still possible to make them variable, but it quickly gets ugly:
final int[] counter = new int[1];
myButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ev) {
++counter[0];
}});
I'm actually willing to live with it (have been for 10 years now), but many
others are antsy to clean up a bit. I'm sure professors don't feel great
teaching those kinds of things to their students either.
I _think_ that's basically all that closures buy us: occasional syntax
clean-up, flow control and special variable scope. You can see though that the
last 2/3 of that are hard work to get right on top of existing JVM technology
and language.
--- ebresie <ebr...@gmail.com> wrote:
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
>
> On Mar 10, 11:01 pm, Alexey Zinger <inline_f...@yahoo.com> wrote:
> > And indeed, one of the suggested implementations would simply consist of
> syntax
> > sugar that recognizes use of single-method interfaces and convert the
> latter
> > into the former at compile time. I know how to type pretty well and I
> don't
> > really mind a few extra keystrokes.
>
> How can you dismiss the cruft surrounding a non-CICE 'Single Abstract
> Method Anonymous Inner Class definition' as simply being something
> solved with a few more keystrokes and not worthy of whining, when in
> the next paragraph you indicate that the ability to bypass the cruft
> introduced by rolling your own 'use an exception to break out of this
> closure and return/break/continue something in the outer scope' as
> crucial? They are two different kinds of cruft elimination. the
Let me clarify it a bit. The way I see it, using anonymous inner classes
implementing single-method interfaces to encapsulate a callable code block
comprises the 20% of closure features that make 80% of people happy. If we
made anonymous inner classes implementing one-method interfaces represented
with special cleaner syntax that still compiled to the exact same bytecode, I'm
ambivalent about it. When I look at code, I don't care what it "reads" like
(within reason), only what it runs like and what it feels like to code against.
From those standpoints, I don't think CICE does not change anything. It's
syntax sugar, which doesn't mean it's bad or shouldn't be implemented, but the
bytecode will be exactly the same.
> exception sugar is more involved, but it also adds a major load of
> complications, primarily when the closure escapes the lifepspan of the
> enclosing method and the whole notion of escaping out no longer makes
> any sense.
My beef with implementing the other 80% of closures, such as more advanced
control flow by use of exceptions is that I _believe_ that it would be an
incredible feat to attempt to make it work without leaking abstraction in some
corner cases. I think it would be asking for a whole other volume of Java
puzzlers. I could be wrong. It's just what my gut is telling me right now,
when I try to think through the potential implementation concerns.
<snip>
> > There's similar issues with variable scope. Currently, anonymous inner
> classes
> > can see variables declared in enclosing scope, but only if they're declared
> > final. It's still possible to make them variable, but it quickly gets
> ugly:
>
> Instead of an array you can also write a Pointer<T> class which is
> slightly cleaner.
> Fortunately all closure proposals (including CICE) address this issue.
Indeed.
> > I'm actually willing to live with it (have been for 10 years now), but many
> > others are antsy to clean up a bit. I'm sure professors don't feel great
> > teaching those kinds of things to their students either.
>
> Any professor that uses java to teach basic programming should be
> fired. I love java to bits, but as a teaching language it's a few
> levels beyond horrible. I question the sanity and intelligence of any
> professor that thinks java is a suitable language for teaching
> programming. Assuming for a moment a competent teacher, closures
> should already be familiar. Then, explaining that in java (without any
> closure proposals, that is), you have to jump through a few hoops to
> get the same result is simply a matter of showing it, explaining what
> and why, and moving on to the next lesson.
I think when ECMAScript 4 comes out, it'll be good. Like everyone else
probably, I think the way I was taught was perfect, which was starting with
register programming on calculators followed by a bunch of fundamentals in a
higher-level language (Pascal) with minimal computer access -- you were forced
to think through your code written out in a notebook so as to find as many
mistakes as possible before you typed it up at a terminal and attempted to
debug it for real. I was just listening to the SE Radio episode with Dick
Gabriel, in which he mentions his sabbatical as a poet and his realization that
art education is all about teaching the artistic process, not specific
techniques, and that the same should hold true for the scientific/engineering
process. Okay, that was a hell of a tangent.
> > I _think_ that's basically all that closures buy us: occasional syntax
> > clean-up, flow control and special variable scope. You can see though that
> the
> > last 2/3 of that are hard work to get right on top of existing JVM
> technology
> > and language.
>
> I wouldn't file closures away under 'syntax sugar'. Closures are also
> a different way of thinking. Whether or not the java world adapts to
> this different way of thinking is another question, of course.
> Personally I prefer CICE because i think it allows for a nicer
> 'evolution path' - you can start by introducing just CICE, then in a
> later version you can stick 'long' returns/breaks/continues into CICE
> with an alternative syntax (using e.g. labels, just like you have to
> with long breaks and continues now), and if people really want it, you
> can introduce the much debated function types.
I don't think of closures in general as syntax sugar, but I do think that CICE
is, and as I mentioned above, it's not meant as a strictly negative judgment of it.
Many good points, Alexey. A few notes:
I don't think its fair to presume a feature to be a bad idea just
because it generates a whole new volume of java puzzlers. Generics are
clearly worth it. I'm aware that generics are somewhat controversial
and there are those who feel they were a bad idea, but I don't. I am
sympathetic to any attempt to improve them (e.g. reifing them), but
given the restrictions of backwards compatibility, generics as
implemented in 1.5 was the only way, and it has made java a better
language.
It has also created a large and extremely complicated batch of java
puzzlers. This does not mean generics is bad. Similarly, just because
closures will enable whole books of new java puzzlers (especially BGGA
closures - or rather, closures that support shorter syntax, function
types, and integrated escape-into-lexical-scope features, which
currently only BGGA is chasing without any reservations) does not mean
they should be discarded out of hand.
It does of course mean that a lot of thought has to go into it.
On Mar 11, 7:01 pm, Alexey Zinger wrote:
> --- Reinier Zwitserloot wrote:
> > > There's similar issues with variable scope. Currently, anonymous inner
> > classes
> > > can see variables declared in enclosing scope, but only if they're declared
> > > final. It's still possible to make them variable, but it quickly gets
> > ugly:
>
> > Instead of an array you can also write a Pointer class which is