vitalyd at gmail.com
Fri Sep 21 10:03:41 PDT 2012
I agree about Optional not being an option where allocations are
undesirable - this is part of the reason where SA via @Nullable is
complementary rather than replacement.
I don't get the part about having to implement Iterable. Why can't you
write some_nullable.or(Collections.emptyList()) as an example, assuming its
storing something that's Iterable? For Comparable, you'd return some Null
object that makes sense to compare if the scenario allows for it.
I don't think it has to be a kitchen sink - quite the opposite actually.
Nor would you use it everywhere as that most likely indicates poor design,
as you say.
Sent from my phone
On Sep 21, 2012 12:37 PM, "Remi Forax" <forax at univ-mlv.fr> wrote:
> On 09/21/2012 06:02 PM, Vitaly Davidovich wrote:
>> They're complementary, one doesn't replace the other. If I'm looking at
>> a diff of a change outside of IDE, I'd like to have more context. I also
>> may not want to pollute my code with @Nullable all over the place.
> I like the @NotNull by default option exactly for that, if you stupidly
> allow null everywhere,
> you ends up with having to annotate your code with @Nullable all over the
> It's a great way to learn how to confine null where it's only necessary.
> Now, to come back to Optional, Java has not a really good way to currently
> deal with null,
> Stephen Colebourne run several polls in 2009  that shows that.
> The real question is does Optional is the good answer.
> There are several issues with Optional:
> - it introduces a cost at runtime (see one of my previous post that
> explain why the
> VM will not remove it) that makes it useless as return value of
> map.get() by example.
> So it's only a solution where the cost of creating an object is hidden
> by the cost
> of doing the calculation in the loop.
> - Optional should implements all methods and do nothing,
> By example, users will want Optional to implement Iterable by example
> to be able
> use Optional in a for-each, or implements Comparable, etc.
> Conceptually, Optional is a kind of kitchen sink but the type system
> of Java will see it
> as an ordinary object. The last time we chose a similar idea, it was
> when we decide
> to do the boxing using plain old Java classes instead of using type
> known by the type system.
> As a result, we can't use primitive type in generics.
> - If Optional is introduced in java.util, we will see types like
> List<Optional<T>>, i.e. types
> that embody Optional, something you don't want with @NotNull.
> I might be wrong, but for me Optional doesn't worth the pain it will
>  http://blog.joda.org/2009/01/**jdk-7-language-changes-**
> Sent from my phone
>> On Sep 21, 2012 11:55 AM, "Remi Forax" <forax at univ-mlv.fr <mailto:
>> forax at univ-mlv.fr>> wrote:
>> On 09/21/2012 05:46 PM, Vitaly Davidovich wrote:
>> > The main benefit of Optional, to me, is that it clearly tells
>> the caller or
>> > receiver that this thing may be null; the conventional way is to
>> > pre/post conditions, but developers are notorious for not
>> reading docs.
>> > Returning/taking Optional is "in your face" - the fluent API is
>> a secondary
>> > convenience/benefit.
>> Any decent IDEs (at least Eclipse and IDEA) understand
>> and can be easily configured to not compile if you try to call a
>> method on
>> something that is @Nullable.
>> Are you suggesting that Optional is a runtime solution to a static
>> analysis problem ?
>> > Sent from my phone
>> > On Sep 21, 2012 11:42 AM, "Zhong Yu" <zhong.j.yu at gmail.com
>> <mailto:zhong.j.yu at gmail.com>> wrote:
>> >> aren't all reference types in Java "optional" already? If
>> "fluent" API
>> >> is desired, is it possible to add methods to the null type?
>> >> Zhong
More information about the lambda-dev