• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • Devaka Cooray
Saloon Keepers:
  • Ganesh Patekar
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
Bartenders:
  • Ron McLeod
  • Frits Walraven
  • Pete Letkeman

Optional for method parameters  RSS feed

 
Saloon Keeper
Posts: 1920
55
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As a side note, Optional is very addicting. I have effectively stopped writing null checks. It makes the code more readable.
The variable should be initialized with Optional.empty();
 
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

salvin francis wrote:I have effectively stopped writing null checks.


I hope not. Optional is not meant for method parameters, and I hope you still validate your parameters before you use them.
 
salvin francis
Saloon Keeper
Posts: 1920
55
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Optional is not meant for method parameters.


Interesting, I haven't passed optional as a method parameter in my code yet. But, I wonder why one should not do that. Let's fork this into a separate thread if the answer is complicated so that OP is not affected.
 
Stephan van Hulst
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It makes your API really unwieldy to use. Passing null into methods should be the exception rather than the norm, and you're forcing the client of your method to keep wrapping their arguments in a call to Optional.of(), just for the sake of making your method implementation more fun to write.
 
Stephan van Hulst
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It would have been permissible if Optional was assignable from the type that it wraps. Imagine that Java had had Optional (or Maybe, or Nullable or whatever it's called in other languages) from the very start, and supported special syntax for it. Then, by default, no types would be assignable from the nulltype:

It would be allowed to assign optionals from actuals, but not the other way around without operating on the optional first, such as using the null-coalescing operator:

Another method from Optional that could be made into a special operator is map(). An example using a combination of null-propagating and null-coalescing operators:

In plain Java, that would be:

Now, you REALLY never have to perform null-checks, because you simply use the actual type in your method parameters if you don't want to allow null.
 
Marshal
Posts: 60845
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What would happen if you passed null to a method taking a non‑nullable parameter? Would it throw an exception?
 
Stephan van Hulst
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. The compiler wouldn't allow you to write code like that.
 
Campbell Ritchie
Marshal
Posts: 60845
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How does the compiler test for an argument which might be null? I know Eiffel use to have the concept of attached types and detached types which might or might not prohibit null, but I have no idea how they are implemented.
 
Stephan van Hulst
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How does the compiler check that you're not allowed to assign null to a variable of a primitive type? All reference types would simply work the same way.

If you have a reference type Foo, you would not be allowed to assign null to it. That also means that the compiler knows that you can assign a variable of type Foo to another variable of type Foo without problems, because a Foo can never be null. You're also allowed to assign a variable of type Foo to another variable of type Foo? . You're NOT allowed to assign a variable of type Foo? to a variable of type Foo, because you might be assigning null. All of this information is available at compile time. To be able to do that, you need to convince the compiler that you've got a backup plan when the value is null. That's what the null-coalescing operator is for.

Another way of looking at all of this is that the compiler will also snap at you if you try to do this:

The difference is that with the special syntax, the reverse IS allowed, and that the compiler automatically wraps the unwrapped object:
 
Campbell Ritchie
Marshal
Posts: 60845
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aaaaaaaaaaaaaaaaaaaaaaaah! Yes, I can see it now. That does sound like the old Eiffel attached type.
 
Stephan van Hulst
Saloon Keeper
Posts: 9385
181
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just looked up attached types in Eiffel, and it's EXACTLY like that.
 
Campbell Ritchie
Marshal
Posts: 60845
190
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That would mean the old way of writing a loop to read every line in a file would be banned:-. . . but the way a Scanner works:-. . . would be all right.
 
salvin francis
Saloon Keeper
Posts: 1920
55
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:It makes your API really unwieldy to use. Passing null into methods should be the exception rather than the norm, and you're forcing the client of your method to keep wrapping their arguments in a call to Optional.of(), just for the sake of making your method implementation more fun to write.


I agree over the wrapping point. While I see Optional as a good candidate for code that's present within the lines of a method, I am starting to realize that outside the scope of a method, it may not be a good thing to do.

Let me summarize for others reading this thread (Open to discussion):
Good usages:
  • within method scope
  • as a method return parameter


  • Bad usages:
  • as a field member
  • as a method input parameter


  • Let me know if you the above list can be improved. +cows for you all !

     
    Stephan van Hulst
    Saloon Keeper
    Posts: 9385
    181
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the cows y'all.

    Yes, that looks about right to me, Salvin.
     
    author
    Greenhorn
    Posts: 8
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    If you're any time in the situation of having a method whose parameter is an Optional or even null, you should heavily consider writing two methods instead, because they do different things. Just write one where the parameter isPresent(), one where it is absent/null.
    Although you might end up with more lines of code, it simplifies the code and makes it more obvious what's going one, because you can name the two new methods accordingly.
     
    Marshal
    Posts: 6126
    418
    BSD
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Salvin, cowgratulations, your topic have been chosen to publish in CodeRanch's Journal April Edition.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!