41–50 of 133 posts
http://en.wikipedia.org/wiki/Null_Object_pattern
It needs static analysis tools such as Code Contracts (C#) or SpringContracts (Java) to make it really robust.
Guava for Java has Optional. Very nice, except for Java's horrid syntax for generics.
Guava is definitely cool and I recommend it whenever I can. It's worth noting, however, that, as a Java library, it cannot provide the compile-time guarantees mentioned in the post. That is, your Option type could still be null and so you're still forced to perform run-time null checking. If you want the full benefit of Option types on the JVM, you might be better off with Scala.
Given an object a of type Optional, we write:
if (a.isPresent()){ MyObject o = a.get() }
Of course, I could still do a.get() without evaluating isPresent() and end up with an java.lang.IllegalStateException. Here, we are "reminded" to do the null check.
Does that article title pass a type checker? How can you compare a type (Maybe) with a value (Null)? Is this instead arguing Maybe vs pointers? No, that can't be right; pointers are just type-safe as Maybe, albeit less general. I guess it's a dynamic vs static typing argument in disguise?
The reason we can compare the type and a value is because they serve exactly the same purpose in different ways. The core argument of the article is that we should get rid of null because Maybe does the same thing in a safer way.
Aha, how timely! I just wrote this post on functors and applicatives that uses Maybe as an example: http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
Earlier quoted context omitted.
The problem isn't just NULL in C. This post is talking about the entire Null/Nil reference problem across all languages that use a null-type value. This is especially a problem in dynamic languages that sling nils around....like any major modern scripting language. Checking if a value is nil before proceeding is aping what a language like Haskell does when it pattern matches against Maybe (Just a, Nothing) albeit in…
That's the main problem with calling Maybe 'better'. If you don't have static type checking then either you implement it just for Maybe or you end up with the same sorts of problems as you had before. Making types non-Nullable by default is nice, though. Even in a dynamic language you can have a syntactic distinction to make interfaces more explicit.
This article makes it seem like you'd have to explicitly check whether a Maybe value is Nothing when you use it. This is certainly safe , but it's also very awkward; as a contrived example, adding two numbers would look like this: case a of Nothing -> Nothing Just a -> case b of Nothing -> Nothing Just b -> a + b This is quite a bit of boilerplate hiding the expression that actually matters--a + b! Moreover, whenever…
You can also make Maybe an instance of various typeclasses for even nicer syntax: instance Num a => Num (Maybe a) where (+) = liftM2 (+) (-) = liftM2 (-) (*) = liftM2 (*) abs = liftM abs signum = liftM signum negate = liftM negate fromInteger = Just . fromInteger > Just 4 + 2 * Just 6 Just 16 > Nothing * 42 Nothing Notice how the fromInteger method allows you to freely mix Maybe and non-Maybe numbers.
Haskell's type classes, unlike ML functors (I think), are "coherent", which means that you can't have scoped or multiple instances for the same type, lest you risk breaking the type system. With that in mind, extending Maybe to Num would mean a reduction the number of type errors caught in other code that uses Maybe and Num near each other.
Does that article title pass a type checker? How can you compare a type (Maybe) with a value (Null)? Is this instead arguing Maybe vs pointers? No, that can't be right; pointers are just type-safe as Maybe, albeit less general. I guess it's a dynamic vs static typing argument in disguise?
No. The idea is that you can get rid of null-the-value by having a Maybe type. They serve exactly the same purpose; having a null value in every type is like making each type implicitly wrapped in a Maybe. The reason we can compare the type and a value is because they serve exactly the same purpose in different ways. The core argument of the article is that we should get rid of null because Maybe does the same thing…
How many problems are actually caused by null (in particular, how many billions of dollars?) While pointers which point into the wrong place for various reasons (off end of array, previously freed memory) cause horrible issues to this day, I can't personally remember ever having a serious issue with a null pointer (they tend to crash quickly and loudly, because in all modern OSes dereferencing NULL segfaults)
They had to "fix" it by blocking userspace memory mappings at the 0th page.
Earlier quoted context omitted.
That's the main problem with calling Maybe 'better'. If you don't have static type checking then either you implement it just for Maybe or you end up with the same sorts of problems as you had before. Making types non-Nullable by default is nice, though. Even in a dynamic language you can have a syntactic distinction to make interfaces more explicit.
True. I think it's also a covert argument for static type checking, though ;-).
I'm sort of a fan of Haskell already, to tell you the truth.
Just x -> something x
Nothing -> halt_and_catch_fire # impossible
One introduces this hack knowing that this particular variable will always be Just and having absolutely no way to deal with Nothing and later somebody else sees the type Maybe Foo and figures that it must be OK to put a Nothing in there.