Serialization opt-in syntax (again)
kevinb at google.com
Sun Oct 7 23:33:23 PDT 2012
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,
> 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...
More information about the lambda-spec-experts