Serialization opt-in syntax (again)
brian.goetz at oracle.com
Mon Oct 8 08:39:26 PDT 2012
Also, let's compare the verbosity problem to the status quo: declaring a
*named* (not even anonymous) class, with a constructor, serialVersionUID
field, etc. (Predicate<String>&Serializable) may be verbose, but its
*nothing* compared to what people would have to do in the absence of a
use-site lambda serialization opt-in (and we're rapidly converging on
that being the alternative.)
On 10/8/2012 4:56 AM, Andrey Breslav wrote:
>> 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?
> I see only two problems there:
> * Allowing this kind of cast only on lambdas, which is ugly, but I'm OK with it.
> * Verbosity: it's hard for me to asses how bad it is as I don't have enough contact with code relying on serialization of behavior. But judging by what concerns Kevin, looks like it may be problematic. I imagine that remembering the name of the target type would be bad enough, and if it has generic parameters, it is even worse.
> Note: The IDE (if one uses it, which is frequently not the case in Google, AFAIK) can help you both write the cast and hide it...
> Andrey Breslav
> Develop with pleasure!
More information about the lambda-spec-observers