Serialization opt-in syntax (again)

[Remi Forax]

On 10/08/2012 06:09 PM, Kevin Bourrillion wrote:
> I agree with all the points in your last flood of responses, Brian.
>
> I'm ready to give up fighting against (Foo<Bar> & Serializable), and 
> we should move toward finalizing that decision, but also (separately?) 
> still evaluate whether it's worth offering the (& Serializable) 
> shorthand as well.  The shorthand has benefits similar to the Java 7 
> "diamond", though I must concede the situation only comes up a tiny 
> fraction as often.

I also agree that we should forget the idea of trying to specify a name 
to provide a better user experience than
with inner-classes.

Brian,
I'm not against the idea to add a way to use & between types in Java.
But there are several issues with the cast and the generics that already 
exist in Java,
by example, a cast like (Foo<Bar> & Serializable) is unsafe and mixing 
type variable like T, U
etc as bound of type variable is restricted.

The other problem is how do you handle the SAM conversion is you have a 
code that use a cast like this:
   Object o = (I & J) () -> { ... };
at runtime, given that the meta-factory has only one SAM type.

cheers,
Rémi

>
>
> On Mon, Oct 8, 2012 at 9:04 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>         I see only two problems there:
>
>         * Allowing this kind of cast only on lambdas, which is ugly,
>         but I'm OK with it.
>
>
>     I don't even think that this is actually the restriction.  Yes, it
>     affects translation of lambdas, but would also work in cases where
>     we currently already allow intersection types:
>
>     <T extends X&Y> foo(T t) { ... }
>     ...
>     Object o = makeXAndY();
>     foo((X&Y) o);
>
>     In fact, the cast to X&Y fills in a current language hole, since
>     there's no way today to say "I *know* this is an X&Y, trust me"
>      We just would not be able to call foo() without knowing the name
>     of the class.
>
>     Admittedly this is a rare situation and has not been a significant
>     problem so far and is clearly not the goal of this effort.  But, I
>     do believe it provides a good example why, in the absence of an
>     "obviously good" ad-hoc syntax, we should lean harder on extending
>     existing concepts rather than inventing yet new ones.
>
>
>
>
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com 
> <mailto:kevinb at google.com>
>