London Lambdas Hackday: Existing Code

[Howard Lovatt]

Re Scoping.

I too find the conversion from inner clases to lambdas and vice versa error
prone.

Since ifs and fors are likely to be less common once a lambdafied
collection library is available, particularly in parallel form, the
'desire' to be like a if/for block is reduced and the 'desire' to be like a
class increased.

On 4 July 2012 01:28, Brian Goetz <brian.goetz at oracle.com> wrote:

> > One of the projects we tried to lambda-ize was vert.x.  This is
> > essentially an asynchronous eventing system (similar to node.js) on
> > the JVM.  This was a big success in the sense that because everything
> > was based upon callbacks to a handler interface, it was incredibly
> > straightforward to lambda-ize and it made code both easier to read and
> > shorter.  Unfortunately it was really too easy - we didn't really
> > learn that much from this exercise.
>
> Well, we learned one thing -- that easy examples just work.  That's
> something.
>
> > My only comment building on this is that variable scoping makes
> > converting anonymous inner classes more difficult than absolutely
> > necessary. The context to this was a programmer converting anonymous
> > inner classes in some existing code to lambdas in order to remove
> > boilerplate.  Due to the fact that the inner function had a variable
> > with the same name as a variable that had been defined in the outer
> > method, he received a “error: variable num is already defined in
> > method” message.
>
> This is one of those things that is still under discussion.  The "no
> shadowing" rule comes from a motivation that lambdas are more like
> ordinary blocks of code (like the body of an 'if') than like inner
> classes, and shadowing is prohibited in those contexts.  But we're not
> sure if this helps or hurts.
>
> > This example spurned some interesting discussion:
> >
> > 1. Guava’s predicates vs Java 8 Predicates
> >
> > People using Guava's predicate library already will have an interface
> > doing something identical to the Java 8 Predicate.  Furthermore they
> > will be able to
>
> to?
>
> > 3. Method References
> >
> > If you heavily use guava's FP constructs then there's an expectation
> > of needing some kind of Function<Foo,Bar>.  In other words if you're
> > using a method reference SomeClass::someMethod, then you expect
> > someMethod to be of type, "Function<Foo,Bar> someMethod()" rather than
> > "Foo someMethod(Bar bar)".  From talking to people, it actually seems
> > like method references are more natural if they're not coming from a
> > guava background.  This isn't just guava - there are several libraries
> > offering a limited range of FP Oriented facilities.  Not sure what can
> > be done about this, but perhaps this is another thing that could be
> > helped with documentation and examples, rather than needing a
> > language/API change.
>
> Absolutely.  Method references are the hidden gem of this whole
> exercise, but will take some time (and IDE help!) for people to realize
> their effectiveness.
>
> > On a related note, it was initially hard to understand where you got a
> > method reference from.  I suspect that this is something that
> > programmers need to just develop a sense for, but there certainly was
> > confusion about static and instance method references.  Some people
> > tried to use SomeClass::someMethod instead of someInstance::someMethod
> > when getting obtaining references.  At a conceptual level it seems
> > obvious if you're referring to an instance method it needs to be
> > associated with some instance, but there is something confusing about
> > this.
>
> Actually, its more complicated than that.  You can take a method
> reference to an instance method in two ways, bound and unbound.  Both
> are useful; I think the unbound form is probably more useful.  For class
> C, if you have an instance method foo of type T->U, then
>
>    C::foo
>
> is of type (C, T) -> U and
>
>    instanceOfC::foo
>
> is of type T -> U.
>
> The unbound form shows up in "map" a lot:
>
>        people.filter(Person::isTall)
>              .map(Person::getHeight)
>              .into(tallPeopleHeights);
>
> Here, the instance is provided by the stream.
>
> > 4. Factory naming conventions don't make sense anymore
> >
> > If you care about API Fluency then you might frequently have factory
> > methods that are named in that style, for example:
> >
> > LocalDate eventDate = LocalDate.from(eventTimestamp)
> >
> > And "LocalDate from eventTimestamp" reads like an English sentence.
> > However when you start to use a factory method as a method reference,
> > the naming convention is totally lost.
>
> Good point.  In this case, maybe better to just use a lambda for
> readability:
>
>    timestamps.map(t -> LocalDate.from(t))
>              .into(...)
>
>
>


-- 
  -- Howard.