A disclaimer or two for Optional

[Joshua Bloch]

I agree with Tim.


Regarding Remi's apologia:

Having == mean object identity was a mistake, albeit one made two decades
ago. Of course it should have been a synonym for .equals when applied to
object references.  But what's done is done.  Support for autoboxing was
another mistake: pretty much the only thing it's used for is collections of
primitives.  It would have been better to support them via some form of
generics that applied to primitives, via heterogeneous translation. It's
amazing how many puzzlers were caused by autoboxing:( Unlike the == flub,
this one would haave required real effort to right, but it would have been
worth it. It might still be worth doing, but probably not.  It would
involve some change to the type system, which is a bad thing.

Given that we did support autoboxing in Java 5, it was a huge mistake to
preserve the meaning of == when applied to boxed primitives.  It produces
the horrible situation where the == operator does something completely
different from <= and >= when applied to boxed primitives. This was common
sense sacrificed at the altar of backwards compatibility. And it would
still be easy to fix this one. Any program whose behavior changes as a
result of the obvious fix probably contained a bug that would be fixed by
the change.

Regards from the Airport Flyer Bus (PIttsburgh, PA),

Josh


On Sun, Oct 20, 2013 at 7:54 AM, Tim Peierls <tim at peierls.net> wrote:

> On Sun, Oct 20, 2013 at 9:13 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>> On 10/19/2013 03:38 PM, Tim Peierls wrote:
>>
>>> I suppose there's no harm in adding this, but I think most people
>>> already get
>>> that a reference to an Optional isn't a meaningful value.
>>>
>>
>> The reaction of others seems to argue for adding the wording.
>> Most people know that comparing Integers via "==" is
>> almost always wrong. (So wrong that autoboxing normally
>> rescues you from this if one of the arguments is an int.)
>> And most people would not even think to do
>> synchronized(Integer.valueOf(**aNumber), and would if asked
>> think that it is such a terrible idea that it is a good
>> candidate to being outlawed.
>> But most people haven't noticed that the same issues apply
>> even moreso to Optional.
>
>
> I think the opposite is true: People are more likely to make mistakes
> because of autoboxing than they are to write code that synchronizes on
> Optional instances or compares Optional references.
>
> The virtue of Optional, in my experience with the Guava variety, is that
> the compiler never lets you forget that you aren't dealing with a Foo,
> you're dealing with a (probably lightweight, possibly magical) potential
> container of a Foo. It's no more tempting to say "synchronized
> (optionalFoo)" than it is to say "synchronized (singletonFoo)". Maybe even
> less tempting, because a singleton at least has a (misleading) whiff of
> permanence, whereas an optional thing might not be there at all.
>
> It's fine to warn people in general about the potential pitfalls that
> exist today or that might arise in the future due to new language features.
> It just seems strange to focus on Optional, a class whose name practically
> shouts to the user, "Don't synchronize on me!"
>
> --tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20131020/c7df99db/attachment.html