Serialization opt-in syntax (again)

[Brian Goetz]

BTW, if we did this, we would have to do BOTH this and the full 
intersection type.  Because, otherwise you would lose the ability to use 
a target-type cast to both provide a target type (if the compiler can't 
infer it) and provide serializability.  In which case the 
(&Serializable) becomes a shorthand for (TargetType&Serializable). 
(And, if we're going to do support such a shorthand, I prefer to have it 
be something that works in more contexts than just serialization.)

On 10/8/2012 2:33 AM, Kevin Bourrillion wrote:
> 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
> <mailto: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
> <mailto:kevinb at google.com>
>