Hmm, it's more strict than I thought (but easier to compile). It seems
you have to be able to add final to the variable declaration. This
compiles fine:
void func() {
int i = 0;
Runnable action = () -> { System.out.println(i); };
}
...but any assignment to 'i', before or after creating 'action',
prevents 'i' from being effectively final.
Hardly a disaster.
I would have also liked to see lexical variable capture.
FFS, I added this (along with closures) to a C compiler before, can't be
too hard (never-mind the eventual fate of said C compiler, but alas, a
sad example of slow compile times and my apparently inability to
effectively debug it...).
more interestingly, they would look just like normal C function
pointers, and survive past the end of the parent scope (unlike, say,
their C++0x analogues, which apparently follow the much weaker/lamer
semantics of GCC's nested functions...).
in the case of lexically captured variables (both captured and mutable),
an implicit heap-based object could be created, representing any such
captured variables.
so:
void func()
{
int i=0;
Runnable fcn = ()=>{ i++; };
... do stuff with fcn ...
System.out.println(i);
}
the 'i' above could be itself folded into a class (any references to 'i'
would themselves implicitly be directed through this class).
sort of like (it compiled to):
void func()
{
private class __cap { public int i=0; } //invisible
__cap _cap=new __cap(); //invisible
Runnable fcn = ()=>{ _cap.i++; };
... do stuff with fcn ...
System.out.println(_cap.i);
}
now, assuming that the variable is effectively final, none of the above
is done, and the variable is copied by value (thus avoiding the cost of
the additional object).
Some corner cases came up, along with some work-arounds. They were
probably recursive. I think assignment rules were altered slightly so
that a lambda body could refer to itself:
Runnable x = () -> { x.run(); };
It was deemed okay to allow this because you can be certain that x will
be ready before it is run.
yep.
still idly thinking here of syntax sugar for SAM types.
maybe even abusing an existing keyword:
public interface void SomeFunc(int x);
implicitly is (more or less) the equivalent of:
public interface SomeFunc
{
public void run(int x);
}
and maybe with a little syntax sugar also on the caller end:
SomeFunc func;
....
func(i); //internally: func.run(i);
....
granted, yes, it is all syntax sugar at this point.
Yes, except I'm not sure how useful it will be in practice with
concurrent APIs. With a serial contract, like a library version of the
for-each loop, it's clearly useful:
interface Block<E, throws T> {
void apply(E val) throws T;
}
static<E, throws T> void forEach(Iterable<E> coll, Block<E, T> block)
throws T {
for (Iterator<E> iter = coll.iterator(); iter.hasNext(); ) {
E elem = iter.next();
block.apply(elem);
}
}
Now the forEach method can generically throw the same set of exceptions
T that the block itself can throw.
But if there is no serial guarantee on invoking the block, you have to
choose whether you return arbitrarily just the first exception thrown,
or pack them into some structure, or something else. I've a feeling
that, most of the time, such methods will require the SAM type to throw
I think they don't foresee such savings for anon classes generally,
because they potentially have fields and multiple user-defined methods.
When you're certain such complexities don't exist, which is the case for
lambdas, certain optimizations become possible.
yes, optimize the special cases, this is generally how it works...
if one tries to optimize for the general cases, then one almost
invariably ends up with much added complexity and generally poor results.
potentially in cases where there is only a single method and no state
capture, ... the VM could potentially internally decay it into being
essentially a plain function pointer or similar (eliminating any class
or instances thereof).
less aggressive would be to only ever create a single instance, and all
references are to this, and probably some special-case call optimization.
You seem disturbingly excited by that!
Here are some arguments about
it (not necessarily mine):
* Function types would introduce a form of structural typing, which
is a little alien to Java. We saw a thread here just a few days
ago ("simple method to simulate function pointers in java"), where
someone was hand-crafting generic function types, and some of the
advice was just to define interfaces per situation, partly because
it documents better, and partly because it's more idiomatic for Java.
* Function types could be added in such a way that they would be SAM
types, so if you can get lambdas to work with SAM types (which
you'd probably have to do anyway to take advantage of old APIs),
they should automatically work with function types added later.
* A limited number of generic SAM types are being defined to extend
the Collections API. They will probably serve as well as function
types in the most common cases.
* If a lambda is always typed as a SAM, how you invoke it is settled
- it's the name of the SAM's method, of course. I recall seeing
proposals where you could write obj(args), or obj.(args), or
obj.invoke(args), where obj was a function type. Leave it as a
SAM, and you don't have to make a decision about that.
lame, IMO...
having spent more of my time using languages with much nicer first-class
functions (yes, I will include C here, as well as JavaScript and
similar...), having to have extra syntax (both to declare and use these
types) is IMO lame.
in all cases, one would type "obj(args)".
idiomatic for Java or not, the more compact declarations and invocations
are more what people who use most other languages are likely to expect
(and ideally the compiler can be smart enough to figure out what
"obj(args)" with a SAM means).
although I kind of doubt this:
has anyone also considered the ability to grab existing methods from
objects/classes, and assign them to new method-fields?... (probably
restricted to a single parent class).
this can be nifty for some types of programs (mostly games, IME), as
then one can more easily have context-dependent methods.
C# also has something like this.
IIRC, no plans for Java 8 - back burner, I think. ISTR some difficulties
arose, so maybe they decided they needed more time for something deemed
not essential.
yep...
this is partly why I continued investing time/effort/... into my own VM
and language-design efforts. mature languages are slow-moving targets,
and so will not be like what oneself may want them to be "anytime soon".
a person may be then better off throwing together their own custom
language with the features they want, and mostly leave the people
working on more mature technology to do what they do well: keep the
thing as a reasonably "solid" piece of technology, as something which
changes too much too quickly may be perceived as being a bit flaky (and
this may actually be the case, if the addition of new features outpaces
things like optimizing and debugging them).
and, at the same time, the person who wants a more specialized language,
can have this as well...
the world isn't perfect but it is generally good enough...
