Serialization opt-in syntax (again)

[Kevin Bourrillion]

Did we rule out

Predicate<String> p = (& Serializable) (s) -> s.isEmpty();
methodExpectingPredicateOfString((& Serializable) String#isEmpty);

?  I realize it's more language-innovating than the full conjunctive
"cast", but it saves all that redundant text...



On Sun, Oct 7, 2012 at 8:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 1. Why I am *against* the *~>* syntax.
>>
>>
>> Serialization is one of the more obscure features of Java. This makes it
>> much more important that to make related syntax *self-explanatory* than
>>
>> for more ubiquitous features.
>> "~>" is about the least self-explanatory syntax we could possibly have.
>>
>
> Totally agreed.  ~> is off the table.
>
>  I'd say those *annotation-based options look most adequate to me*.
>>
>> (In the issue tracker there is some consensus of two more people about
>> this, so I'm the third)
>>
>
> Yeah, its pretty attractive -- from the end-user perspective.  Except that
> after reviewing the options I just don't think this is going to be
> acceptable to us.  While it doesn't create much new syntax, it does cross
> some big lines we have spent eight years deliberately not crossing:
>  - annotations don't affect language semantics
>  - annotations don't affect bytecode generation
>  - can't annotate expressions
>
> While there are lots of people who want annotations to be something they
> are not, what they are is deliberate and I'm not looking for an opportunity
> to make that radical change.  (Also, the work of creating new targets like
> "lambda" for annotations is far more significant than some of the other
> approaches, and we're very short on time.)  What annotations are and aren't
> is already a confusing and contentious enough topic; this would further
> blur the boundaries in ways that might be convenient in the short term but
> problematic in the long term.
>
> So I think we're going to have to take annotations mostly off the table,
> too.
>
> The approach I have come to prefer is a target-type approach, because this
> is most consistent with how lambda translation is driven now, and most
> consistent with how objects become serializable in other situations (by
> extending Serializable).  Of the target-type options, the intersection type
> cast seems the obvious choice because (a) the syntax already has precedent
> and (b) we may well want to expand the set of places where intersection
> types are allowed in the future, so it makes more sense to extend an
> existing concept that we might extend further anyway than create a new
> dead-end special-case concept.
>
> There are some others (notably keyword) that are not outright
> unacceptable, but still seem less desirable than just using the (admittedly
> verbose) target type approach.
>
> So, let's go back to where I set the bar earlier this week: aside from "I
> like XYZ better", are there any reasons why the intersection type cast
> should be unacceptable?
>
>


-- 
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/20121007/bf206609/attachment.html