Serialization opt-in syntax (again)
Brian Goetz
brian.goetz at oracle.com
Sun Oct 7 20:13:32 PDT 2012
> 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?
More information about the lambda-spec-observers
mailing list