Serialization opt-in syntax (again)

[Kevin Bourrillion]

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.


On Mon, Oct 8, 2012 at 9:04 AM, Brian Goetz <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20121008/cac6f48b/attachment.html