You can use *any* collection type if you want, just be careful to guard against mutation and not allow it to grow beyond one element. That said, Arrays offer the best performance if taking this approach (no boxing of primitives!).
Nat Price's solution does offer some nice extra goodies though, `otherwise` is very handy for providing default values and `to` for working with guava functions is a godsend. All of this stuff makes a lot more sense and becomes a lot more powerful once you have higher-order functions in your toolbox, so I reckon we can expect to see a lot more of it once lambdas go mainstream. On 5 June 2012 21:28, Graham Allan <[email protected]> wrote: > My 0.02c, FWIW. > > I have found using a variant of the Option notion quite satisfying in some > use cases. In my case we use Nat Price's Maybe for Java, but it's > essentially equivalent[1]. (I'll use the term Option here for consistency, > though the API of the two things are not the same) > > What I have found is it tends to be more useful as return values rather > than parameters. For example, it is possible to have methods where they can > be invoked correctly, in the right state, but still have no 'correct' > return value. As a trivial example consider a Person class which contains > an optional middleName property. Throwing an exception when you ask for the > middle name in this case would be really unfriendly, since nothing > exceptional has occurred. You could return null, but it could be easy to > forget to check. Having the compiler tell the callers that they may not get > something they're expecting, rather than it being a runtime null value has > been quite elegant. > > Of course, if the same Person class has a firstName property, and you've > decided it's mandatory (possibly at the database level as well) then it is > just a plain bug if it returns null, I wouldn't expect to find a usage of > Option here, and I'd be upset if someone used it to mask the bug. > > When callers get the Option returned, *they* decide on the correct > behaviour when it's absent. That can be choosing a default value instead > (e.g. empty string, empty iterable); throwing an exception if it makes > sense for them; applying a function to the value if it exists; or > propagating it as a return value up to the point where the decision should > be made. For me the use of Option essentially boiled down to distributing > responsibilities: the thing that produced the Option result shouldn't > necessarily know how to handle the cases where a value is present or > absent. Using a type to document that is much clearer than > Javadoc/annotations etc. > > There's nuances and trade-offs, of course, but I've found using an > Option-like thing in Java to be pretty useful. > > Kind regards, > Graham > > > [1] https://github.com/npryce/maybe-java > > On 5 June 2012 20:12, Cédric Beust ♔ <[email protected]> wrote: > >> >> On Tue, Jun 5, 2012 at 9:42 AM, Kevin Wright <[email protected]>wrote: >> >>> "Going bang" really isn't your friend >> >> >> This is like saying "having bugs is not your friend". >> >> Well, doh. The question is not about having bugs or not, it's about >> detecting them as soon as possible. >> >> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
