What is the meaning of this?

[Osvaldo Doederlein]

2010/2/2 Joshua Bloch <jjb at google.com>

> Osvaldo,
>
> Of course we all believe that we should "design functions [lambdas] as well
> as we can."  But we disagree about what constitutes quality. I'm deeply
> concerned about consistency with existing constructs, and conceptual surface
> area. Java currently has two main  families of types: primitives and object
> reference types. Object reference types are further subdivided into
> interface types and class types. Arrays are class types. When we added enums
> and annotations, they fit conveniently into class types and interface types
> (respectively). As we add function types and expressions for producing
> instances of these types (lambdas), we should try as hard as we can to make
> them fit into the existing type framework of the language.
>

I agree, these principles are not even debatable - we need to fit new pegs
in existing holes, as neatly as possible. A perfect fit is seldom possible
when the core language is not really extensible. Even for something as
simple as enums, Java5's solution had important tradeoffs (no compatibility
for the enormous legacy of sets-of-int-constants used as enums; no switch()
over enums except in the enum class).

The debate happens where there are many possible ways to obtain the desired
consistency, because there are many existing constructs and concepts to be
consistent with and you often ought to pick priorities. A function type
should certainly be a reference type, but... should they have some standard
root type (like Enum and Annotation)? Should lambda conversion support any
SAM type, or just SAM interfaces? Should every lambda expression produce an
object with unique identity? Could a lambda be a simple MethodHandle,
without any wrapper around that when not necessary?

To summarize my POV, I think the lambda concept should not be tied to its
implementation (whatever code that javac produces), and it should not be
tied to the needs of SAM types (this is strictly a backwards-compatibility
feature: the tail shall not wag the dog; if we need some ugly exceptional
cases for SAM conversion in exchange for cleaner lambdas everywhere else,
that's the right tradeoff IMO). A function type is a reference type, but
lambdas are not always bound to variables. Lambdas should not be forced to
look like methods-of-objects, complete with a self-referent 'this'. Lambdas
that must be represented as instances but don't capture enclosing state
should not be forced to be unique instances. And when one asks the question
"What if the programmer writes some code that expects a lambda to be a
[unique] object, or compiled to a certain pattern code, and uses
typecasts/reflection/whatever to write code that's hardwired to that", well,
my answer (educated version) is that this user won't be using the language
correctly, just let his code fail or be non-portable or suffer incompatible
linkage changes. Some bad things can be prevented by the language or javac
(e.g. make synchronized(<lambda/function type>), and other unreasonable
usages, illegal - or at least issue a warning). The current language and
APIs are already shock-full of ways to shoot yourself in the foot,
especially when you blatantly disrespect or ignore the language or API
specs. In another thread, we're rehashing the debate of autoboxing - yeah,
people can rely on identity guarantees that are not valid for cached
Integers, they can write dumb code that uses equality comparison over
Integers outside the guaranteed-cached range (or mixing in some Integer that
was not produced by the caching factory API), or maybe synchronize on its
monitor, and that code will behave differently in another JVM, and may bomb
with severe and random / dificult-to-reproduce bugs like deadlocks. When
Java5 was designed, we just said: just screw the programmer who does this,
because autoboxing is very good and caching is critical so we won't make
unreasonable compromises.

A+
Osvaldo


>
> That does not mean that we can't invent any new concepts. Enum types were a
> new concept, but they meshed well into the existing type framework, and most
> Java programmers found their use to be comfortable and intuitive. They could
> pretty much guess what code using enums did without reading a spec or
> tutorial. That's what we're aiming for.
>
>           Josh
>
>
> On Tue, Feb 2, 2010 at 12:24 PM, Osvaldo Doederlein <opinali at gmail.com>wrote:
>
>> I agree too (with Mikael/Rémi/Neal). And I add that, it worries me this
>> (apparent) thinking of "we cannot add new concepts to the language" - if
>> this is not Josh's position, it boils down to that in practice: i.e., in
>> Java there are only methods-inside-objects (or classes for statics), even
>> inner classes are very explicitly methods-inside-objects, so any new
>> construct to contain code must be a method-inside-object... we can't have
>> a
>> fundamentally new construct, like a function/closure/lambda. We can only
>> have something that _looks like_ a function/closure/lambda but is firmly
>> rooted (both syntactically and semantically) in the method-of-object
>> concept, down to backwards-compatible behavior of 'this', identity /
>> memory
>> allocation, etc.
>>
>> With such restrictions, Java is doomed to evolve only in the most
>> cumbersome
>> way possible, every new feature always paying enormous tradeoffs not only
>> to
>> backwards compatibility (which is already often a big hit - and I agree
>> that
>> cannot be avoided), but also to the backwards thinking - let's not invent
>> any really new concepts because most developers are idiots who can't learn
>> that a function is something different and will certainly write all sorts
>> of
>> evil code that will fail or not be portable...
>>
>> I say, let's design functions as well as we can (ok as well ss you can - I
>>
>>
>> 2010/2/2 Mikael Grev <grev at miginfocom.com>
>>
>> > I must, slightly reluctantly due to historic reasons, agree as well. No
>> > matter how things are turned lambdas is something new and the object
>> > implementation should not shine through if not needed or shown
>> advantageous.
>> >
>> > Also, I have always thought declaring a variable as 'volatile' would've
>> > been a better solution than forcing it to be final since so many go
>> around
>> > that anyway. I know I do sometimes, and I just feel dirty when I do, for
>> no
>> > good reason since I know what I'm doing (most of the times anyway. Can't
>> > think of a bug introduced that way).
>> >
>> > Cheers,
>> > Mikael
>> >
>> > On Feb 2, 2010, at 19:48 PM, Rémi Forax wrote:
>> >
>> > > Le 02/02/2010 19:40, Neal Gafter a écrit :
>> > >> I think Zdenek had it exactly right.
>> > >>
>> > >> A lambda expression is not an object creation expression.  The
>> function
>> > is
>> > >> not declared within the scope of some object type.  A lambda is
>> written
>> > as
>> > >> an independent block of code, and should be scoped accordingly.
>>  Trying
>> > to
>> > >> make a lambda act the same as an anonymous class creation expression
>> > smacks
>> > >> of cargo-cult language design.
>> > >>
>> > >
>> > > I agree. Lambda is an anonymous function.
>> > >
>> > >> Cheers,
>> > >> Neal
>> > >>
>> > >
>> > > regards,
>> > > Rémi
>> >
>> >
>> >
>>
>>
>