Serialization opt-in syntax (again)
brian.goetz at oracle.com
Mon Oct 8 08:24:01 PDT 2012
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
> 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
> 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>
More information about the lambda-spec-observers