Regarding your last argument, you could easily check in the proposed AS3 version if the User object is the EmptyUser or the NullUser if you are interested in that information. This information is not lost.

Basically, the idea is to get rid of null since it makes it cumbersome and error prone to write code. The Scala compiler would also warn you for instance if your match is not exhaustive on the Option[T] and this makes it an even better feature.

If you do not consider null values that bad, check out the link from Maxim :)

The difference between the invalid and offline users has been abstracted into the body of ‘get_user’ method, and so the context keeps running logic that assumes user exists, when in fact he does not. I would say, if there is a need for code that needs fewest lines to do what it does, simply make ‘get_user’ old-fashioned (return null on invalid users) and call it in turn from another abstraction context, something like an ‘if_logged_in’ procedure which will trace the ‘Hooray’. Just as readable, but arguable more optimized.

function get_user(id): IUser
{
// return an IUser or null when no user by given id
}

function cheer_if_user_logged_in(var id)
{
var user = get_user(id);
if(user == null) return;
if(user.isLoggedIn) trace(‘Hooray!’);
}

cheer_if_user_logged_in(); //An abstraction for a very specific case

I consider the following equally viable and maintainable as your example, if you disagree you are welcome to state your reasons:

Joas approach however is closer to true polymorphism, because the context of obtaining a user object reference does not to know the type of returned value and explicitly account for the ‘user not found’ error – it always returns an object expected to be able to be called ‘isLoggedIn’ on, even for users that do not exist.

In my opinion however, it is an abstraction that is not really necessary. I do acknowledge its need for readable code, but I do not consider ‘null’ values that bad. Null is just a special value that indicates error condition, just as None or Some types are, but in case with the latter, they have to define the ‘isLoggedIn’ method which frankly makes no sense for users that do not exist. I value semantics over code readability.

You can actually do the same in haXe :

enum Option {
None;
Some( v : T );
}

var x = None;
var y : Option = Some(56);

switch( opt ) {
case None: // handle the “null” case
case Some(v): // “v” is the actual value (not null)
}

I would ask, why would a developer design their application in a manner that allows a situation where nulls pop up?

In the example accessor, getUser(id: String), I’d argue: Why is an invalid ‘id’ being passed in?

If you do have a design whereby the developer can’t control what
‘id’ is being passed, I’d suggest this:

if(isValidID(id))
{
var user = getUser(id: String);
passUserToClientObject(user);
}
else
{
Alert(“No User Exists”);
}

Anyone’s thoughts…..

Thanks for the article!

Maxim: Thank you for the link!

Macaca: True, you can generate a lot of files but your SWF will get bigger and bigger. Besides, what if you figured out that you have a bug in your template? :)

James: I have had a look into the compiler. I am highly interested on getting Scala running inside the Flash Player and would be willing to invest time. That would be spring next year and definitely after Scala 2.8 has been released.

Great post! Want to port Scala to run on Flash Player? I talked with Martin Odersky about this a year ago. He said it’s certainly possible he just doesn’t have the time. Scala on both sides of the wire! That would be very cool.

-James

On generics: FDT templates work to some extent if you establish a good convention (but oc they just generate source code).

Further reading:
http://martinfowler.com/eaaCatalog/specialCase.html
http://en.wikipedia.org/wiki/Null_Object_pattern

This post was mentioned on Twitter by retrogamer4ever: RT @joa: New blog post: Getting Rid of null http://bit.ly/31Uk0h...

In the case above, I would not create a custom Null class, because from my perspective it’s not a “class” of user or a new type. Rather, I’d create a null-valued user, i.e. User.NULL (which may in turn get its value from a NullClass like you showed).

Semantically, null is a object-reference value (just like 0 is a Number value or “” is a String value). For many custom types (classes), there are semantic “nulls” or “undefined” that should be provided by a complete API.

Thanks for the info on Scala… really need to dive into a functional language these days… it’s been years!