Project Lambda: Java Language Specification draft 0.1.5

Reinier Zwitserloot reinier at zwitserloot.com
Tue Feb 16 08:21:39 PST 2010


Why can't I thwart them?

You're complaining about something being new and unfamiliar to java
programmers, and I'm replying with: Yes. That's because it's new. Seems
tautological when you put it that way, doesn't it?

What's your opinion about the notion that the way lambda-dev is going,
closures are a new and unique concept, and Joe Java is going to have to
understand this concept, which very much includes the idea of having an
'unnamed method', in order to work with Java7? If you agree, it would seem
that avoiding x.() syntax is not going to make any difference in the amount
of understanding Java Joe needs to do, and thus makes that particular
objection to the syntax irrelevant.

In other words, I'm with Jesse Kuhnert on this one. It IS different, so
making it look different is good.

--Reinier Zwitserloot

On Tue, Feb 16, 2010 at 4:32 PM, Paul Benedict <pbenedict at apache.org> wrote:

> To your definition of the PLS, I don't think there is an official
> definition. However, exempting the native types of Java, everything is
> an object (even methods). To have over a decade of Java invoking
> methods on objects, and then suddenly introducing an unnamed method --
> and not requiring a method name -- can't thwart objections under the
> tarp of "it's a new language feature".
>
> On Tue, Feb 16, 2010 at 6:55 AM, Reinier Zwitserloot
> <reinier at zwitserloot.com> wrote:
> > That's not the principle of least surprise. The PLS means: If a
> significant
> > chunk of those people using it think a certain library call or construct
> > does X, and believe this is sufficiently logic to not immediately dive
> for
> > the documentation, but this call or construct actually does Y, that's a
> > violation of PLS. That's _clearly_ not happening here. The only possible
> > expectation here is that "foo.()" is simply invalid syntax, but this
> > argument feels like weak tea to me: You can make that argument against
> just
> > about every new language feature.
>


More information about the lambda-dev mailing list