Optional -> OptionalResult

[Ali Ebrahimi]

+1 for language support.

Maybe using new jsr 308 and built-in java compiler plugin: @NotNull checker

@NotNull String str = null; //compile error

@NotNull String test(@NotNull String a){
...
     return null; //compile error
}

test(null) //compile error

String nullable = someMethod();

@NotNull String nonNullable = nullable; //compile error: incompatible type

this way we guarantee don't get NullPointerException anyway and don't need
handle that.

another and similar solution is introducing a syntactic sugar for
non-nullable types.

@NotNull String  <=> String!





On Wed, Jun 5, 2013 at 5:12 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 06/05/2013 12:49 PM, Peter Levart wrote:
> > I'm not talking about "how nice" the code looks when using such API but
> > "what can" be accomplished by using it. Of course with language support
> > like ?. and ?: the code would could look much nicer even without
> Optional.
>
> +1,
>
> and better if Optional is an annotation/keyword, that forces users to
> use ?.,  ?: or a null check
> so have the same guarantee that Optional as a class without the overhead
> and without a way to stick Optional in a middle of angle brackets.
>
> A lot of people find that Java should do the boxing transparently, but
> adding a class Optional/Option/Maybe
> to manage null goes in the opposite direction by forcing users and
> writers of API to do the boxing (of null) by hand.
>
> Basically I see Optional/Option/Maybe (or any boxing of null) as a
> solution based on a design pattern.
> Most of the design patterns are created because of a lack of support in
> the language.
> So instead of using a design pattern why not adding support for null
> management directly in the language,
> we are talking about Java here, a language that has always evolve and
> will continue to evolve.
>
> >
> > Regards, Peter
> >
> >
>
> cheers,
> Rémi
>
>
>