Method Pointers
Greg Dennis
gdennis at alum.mit.edu
Sun Feb 26 20:11:06 PST 2012
Have you considered allowing a cast to an intersection of types, e.g.
allowing a cast to "(Runnable & Serializable)"? It's not the most succinct
option, but it avoids the creation of the garbage class, and the concept of
an intersection type already exists in generics.
Greg
> Date: Sun, 26 Feb 2012 18:48:57 -0500
> From: Brian Goetz <brian.goetz at oracle.com>
> Subject: Re: Method Pointers
> To: Sam Pullara <sam at sampullara.com>
> Cc: lambda-dev at openjdk.java.net
> Message-ID: <4F4AC4E9.6090109 at oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> I would call this the "do nothing" option (which is certainly an
> option), because we already support this as part of the basic SAM
> conversion. You can use a cast to select a specific target type, and if
> the target type is serializable then the lambda will be. But, it still
> is in the sucky category as a use-site serialization opt-in because it
> requires the user to create a class just so they make a lambda
> serializable (and if this were the only option, which it currently is,
> the result would be an application has many otherwise useless "garbage"
> classes like this one.)
>
>
> On 2/26/2012 6:43 PM, Sam Pullara wrote:
> > Since we are going to support it when the interface is Serializable, why
> not just require that you do something like:
> >
> > interface SerializableRunnable extends Runnable, Serializable {}
> >
> > and then cast it to that at the call site. Is this an option that sucks?
> >
> > Sam
> >
> > On Feb 26, 2012, at 3:29 PM, Brian Goetz wrote:
> >> Another use-site opt-in would be explicit serialization support. While
> >> we plan to do at least as well as inner classes -- a lambda is
> >> serializable if its target type is -- we'd like to do better, and
> >> provide a way of opting in. This largely turns out to be a syntactic
> >> problem -- what is the syntactic form of the opt-in. (Lots of
> >> suggestions have been made, and so far they all suck. I will open this
> >> to suggestions at a future time, but until then, please hold your fire.)
>
More information about the lambda-dev
mailing list