for (CapabilityClass17 cap : getAdapter (CapabilityClass17.class)) {
// do something with the extended API
}

Ironically, if you think your class had to behave like a list, and you add that adapter later, you could actually get some kind of real looking for loop :)

for (Object s : getAdapter (List.class)) {
// Booya :)
}

As for the type of the iterator, maybe super type tokens can help.

I’ve read the GoF Book 15 years ago, taught them to lots of students and used them in lots of projects. I think the Null object (though not from the GoF book but from Fowler several years later) is used not often enough. Recently I introduced NullId to a project (with a nice isValid() method) with very good results. More people should do that.

“Search for design partners or GoF.”

Search for Refactoring and Fowler for the Null object pattern.

Nonetheless Option/Maybe is something different.

if (x != null && y != null) {
return x y;
}

…and much more readable.

Perhaps you should use try to some patterns that are better fit
for Java like Visitor mentioned by James or Null object. Search
for design partners or GoF.

Don’t get me wrong, monads are cool but can’t be expressed
in Java at this time. Perhaps if Java7 incorporates closure
proposal, we’ll be able to express something like:

withObjectsThatArentNull(x, y) {
return x y;
}

The double loop is a nice construct. Hats off for thinking of that and the anology to Scala and Haskell with for and do. Especially “for” :-)

I have to say, it’s a nice hack.

Another way to deal with Option/Maybe in Java is to use the visitor pattern. I wrote a quick one for Tony Morris and he used it in a presentation on Scala (where he called it OneOrNone). The relevant slides are at

http://projects.workingmouse.com/public/intro-to-highlevel-programming-with-scala/artifacts/latest/chunk-html/ar01s08s02.html

and

http://projects.workingmouse.com/public/intro-to-highlevel-programming-with-scala/artifacts/latest/chunk-html/ar01s08s03.html

However, as Jevgeni points out, the real nifty bit about Option/Maybe as a monad is composibility. E.g. in Scala

val maybeSum = for {
x <- someMaybe
y <- someOtherMaybe
} yield x + y

or Haskell

let maybeSum = do
x <- someMaybe
y <- someOtherMaybe
return x + y

The iterator trick in Java, by contrast, yields the following

Option[Integer] maybeSum = new None[Integer]();
for (x:someMaybe) {
for(y:someOtherMaybe) {
maybeSum = new Some(x + y);
}
}

Still, that’s much nicer than the manual instanceof/extraction I had and a bit nicer than using a bunch of nested visitors. Hats off!

[Ed: Added + see next comment]

@BoD: a.) The developer has to deal with the None case, with NULL he can just ignore it b.) The developer knows there is a None case, with NULL he can’t see it in the method signature. And see the linked posts: NULL can mean lots of things (error, no result, etc.), None is much better.

for (String name: option) {
// do something with name
}

better than

if (name != null) {
// do something with name
}

@Cedric: Thanks. From an unrelated post “Others I’d like to meet are above all Crazy Bob for Dynaop (and Guice), Cedric for his stand on dynamic languages and Rickard of course.” ;-)

@Jevgeni: Yes, of course your’re right. That wasn’t the focus of this point. While this isn’t that powerful for Option, combination and mapping is very powerful for Either.

// NULL name
Collection name = Collections.emptySet();

// Value
Collection name = Collections.singletonSet(“Joe”);

for (String n : name) {
// Do something
}

IMHO… Not a good idiom. It’s to much work to prevent NPE and would confuse whoever needs to maintain code.

“And then you return 2 names from the getName method and you a buggered…”

The return type of the getName() is Option[T], so you can’t return more than one without changing the signature.

In the case that you don’t declare the return type in your client code:

a.) If your code handles 0 or 1 return values (None/Some) with a for and does something, like add the name to an index, or add the name to a cache, or validate the name, then your logic also works for more than one name. And you don’t need to change the client for loop of your code.

b.) If you need to handle 0 and 1 and n in different ways (what most often you don’t), then the for hack isn’t suitable of course.

“I think this for loop would just confuse me in a months time, [...]“

Not if you think of an Option as a 0..1 element container.

I think this for loop would just confuse me in a months time, not to mention my collegues.