What is the meaning of this?

[Joshua Bloch]

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.

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
> >
> >
> >
>
>