Serialization opt-in syntax (again)

[Brian Goetz]

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
> http://jetbrains.com
> Develop with pleasure!
>
>