Monday, March 3rd, 2008

Playing with language: Inlined fromMaybe

Category: JavaScript

Oliver Steele continues to spend time thinking about languages in his recent post on More Monads on the Cheap: Inlined fromMaybe.

He details the pain of dealing with nulls and various checks:

This article is about how to deal with null values. It follows up on this one. It’s intended for code stylists: people who care a lot about the difference between one line of code and two, or keeping control statements and temporary variables to a minimum. (A code stylist is kind of like the dual of a software architect, although one person can be both.) It’s not about code golf — although you might learn some strokes to use on that — but about keeping the structure of your code, even at the expression level, close to the way you think about the problem, if you think like me.

If you’re not a code stylist — and I’m not saying that being a code stylist, any more than being a prose stylist, is either a good or a bad thing — you might find it baffling that someone would put so much time into such simple topic. I won’t try to convince you otherwise. In that case, you might want to check back next week, when I’ll move back up to the bigger picture. (Specifically, some fun stuff involving how to use meta-object programming to solve race conditions in client-server models.)

He ends up with an inline fromMaybe solution:

To change code that expects a non-nullable array to a nullable array, change array to array||[]. This is a local transformation: it changes an expression into an expression (not a statement), so you don’t need to re-write the code that contains it. It’s also a linear transformation (again, in the sense of linear logic, not linear algebra): an expression that only occurs once before the transformation, only occurs once after it.


  1. var count = (products || []).length;
  2. var value = parseInt(inputString || ‘0’, 10);
  3. var option = ({key:‘default’}.key;
  4. var result = (fn || Function.K(defaultValue))(argument);
  5. sprite.moveTo(x || 0, y || 0);

Posted by Dion Almaer at 7:01 am

3.2 rating from 14 votes


Comments feed TrackBack URI

This seems like a nice way to write less code – on the other hand, in JavaScript at least, you are better served by type checking. In the example…
var count = (products || []).length;
… it is quite possible that products could be a boolean value of true, in which case that expression will try to get the length property on a boolean value, which will throw an error. Maybe the examples provided are a good way to write less code – but less is not always better.

Comment by wralias — March 3, 2008

@wralias: The method should define what values it expects the user to supply it with. If it specifies products to be an array or null, then this is an elegant and complete solution. If it allows products to be a boolean, then it is an incomplete solution. It all depends on how you are planning to allow your methods to be used. Otherwise it’s just garbage-in garbage-out.

Comment by Anonymous — March 3, 2008

“the method should define what values it expects the user to supply it with”

I wholeheartedly agree. Something like this:

* @param {Array} a
* ...
var thing= function(a, b, c) {
var a = typeof a != "object" && typeof a.length != "number" ? [] : a;

…might be all the stylin’ you need!

Comment by wralias — March 3, 2008

If a variable named ‘products’ is a boolean, you have other things to worry about.

Comment by Tim Cooijmans — March 5, 2008

Leave a comment

You must be logged in to post a comment.