[Update] I filed a ticket on the mochiweb google code site, and they pointed out that this IS expected behaviour. Mochijson2 expects binary strings, which makes good sense since when you decode with mochijson2, strings are converted to just that! Also, string operations in Erlang are faster on binary strings (or so I’ve been told). See the gist for an example.

So I’m working on my test coverage for grove, which has been otherwise abysmal and late to the game. The bright side is that I caught some funnyness with my testing that I was not dealing with before, and I thought I would share my good fortune with everyone.

Notice I said funnyness and not wrongness, this may be the intended behavior but I was not expecting it.

I realized this once I started building my unit tests because I’d been dealing with atoms and numbers ONLY for the value position of those key/value tuples. Obviously I thought it a bit odd when the string result I got included and array of integers where I expected to see a string.

Solution: use mochijson. Not sure why I was using 2 in the first place.

Blah, blah worthless post, _but_ I am constantly reminded why testing makes the world a better place. To take it a bit farther I’m going to borrow a story my high school econ teacher, Mr. Werbylo, told me to explain why we shouldn’t sit on the desks in class:

Look, [ these desks are old < => programming is hard ].

If you [ fall of the desk < => don't build unit tests ] you’re going to be hurt and everyone is going to laugh at you for your clumsiness. Most people think the story ends there, but it doesn’t. When you get home, you’ll still be angry and you might kick your dog. Your dog, being angry and sad from the physical pain you’ve caused him will bite the mailman. And finally, ultimately, the mailman will go to work the next day with an Uzi and kill everyone.

That, is how [ falling of a desk < => failing to get test coverage ] causes loss of life.

One of my favorite teachers.

[Update] I did some refactoring that I’ve been meaning to do thanks to ayrnieu in #erlang.

So as I’m hacking my first Erlang project I’ve come across a few places where I was unsure what would generally be a more readable/understandable/robust solution to a given problem. The one I’m thinking about right now is using pattern matching in my function definitions or, alternatively, case statements. I’m hoping someone from the community might be able to shed some light.

Part of the project I’m working on turns a tuple like:

into a set comprehension like:

As you can see my goal is to be able to query Mnesia, or rather to produce a standard way to query any data store. The following function definition and support functions do the work:

The tuple is “filtered” down the function definitions, and when each tuple (columns, operations, etc) is handled it is translated into a string and thus not matched again until ultimately the final definition concatenates all the pieces together to build/return our query. I REALLY like the way this works in that its short and simple. Also the tuples could in theory be replaced by an appropriate string built outside the function and it would still work, which makes it more flexible.

It has other issues, such as its fragile ordering requirement. If its not ordered properly it may break, or worse just not form the comprehension properly. Which leads me to wonder if there’s a better way to implement this, even if its not _quite_ as concise.

The following is a quick hack and not tested but another way to handle it might look like:

Honestly, I can’t say which would be better as I haven’t tried replacing the version I’m using with a case statement. Is there even a third and better way to handle this situation? Or is this just a case of agonizing over the fork or spoon for eating your pie: doesn’t really matter both will work equally well.

Also, I am proposing a new term for pattern matching in function declarations:

patmatchlarations!