Updated State of the Lambda

[Reinier Zwitserloot]

On Wed, Oct 20, 2010 at 10:04 AM, Howard Lovatt <howard.lovatt at gmail.com>wrote:

> 2. I agree that abstract classes as SAM types are desirable, but the
> construct:
>
>   AbstractClass ac = #{ ac.sam() };
>
> will be confusing because people are used to qualifying with a class
> name, not an field/variable name. Also rather defeats the point of an
> inline definition since it must be on a separate line.
>


I don't have solid numbers for this, but think of the practical use case:
You'd almost NEVER need to call your own SAM types' methods. For all
interface SAMs (which I'm guessing are going to be the (vast) majority of
SAM types), there's absolutely no point. How often do you need .clone(),
.equals(), .hashCode(), or wait/notify stuff on self, and how often do you
need to recurse? Virtually never. On the other hand, calling the container's
.toString() sounds like something I might do rather a lot.

For AbstractClass SAMs there's more utility in calling self. Some sort of
DSL-ish approach where a bunch of utility methods are defined in a class
SAM. This particular use case is hurt quite a bit by the DA/DU trick, but
there are alternatives: static imports, and using an anonymous inner class.

A solution where either kind of call is trivial would be nice, but one of
the two (calling members of outer, or calling members of inner), is going to
require some sort of somewhat annoying hoop to jump through. It should be
calls to inner self that require this awkardness and not calls to outer,
because calls to outer will be far more common (again, gut instinct, but
probably not that hard to verify with a few large codebases and the right
analyser).