A units-of-measure implementation in JavaScript

I made something kinda interesting this week in JavaScript. It probably qualifies as “over-engineering”, but it was for my use, to meet my needs, and I had making it, and I’m having fun using it (so there! :-p).

It’s an implementation of measurable units of various types that I tend to use in my recent JavaScript-games-making excursions: such as seconds, milliseconds, pixels, radians, and frames. It lets you express that quantities are in rad/s, f/s, px/s^2 (for acceleration values), etc, and convert between them via multiplication and division (px/s divided by a time value results in px/s^2 (pixels-per-second-per-second), or if multiplied produces a value in number-of-pixels). It throws an error if you mix up which units you meant to use, which helps enforce the sanity of the arithmetic you’re performing.

Usage looks something like this:

The reason for this little library is that I’ve frequently run into problems thinking in the wrong units in my games. One variable might hold a length of time in seconds, another in milliseconds (from new Date()), and I’ll try to use them together, forgetting to convert between them. In MajicUnits, they’re all represented in seconds under the hood, and I can specify what unit I want when pulling them back out.

Or I often forget to scale a velocity or acceleration by the inter-frame time before adding to current state, resulting in a full second’s acceleration taking place in a single frame. Using MajicUnits, I’ll see an exception thrown if I forget to multiply by the frame delta.

It’s the sort of stupid error that led to NASA losing its $125 mil Mars orbiter because one group coded for metric units while another used imperial. If you have a language to express (and enforce!) unit types being used, you’ll catch the problem. Better, of course, if you can do it at compile-time, without requiring the offending code to run before you can catch it, but this is JavaScript, and writing my own to-JavaScript compiler that adds units of measure as strictly-enforced types at the language level would be really drastically over-engineering. 🙂

The library’s pretty crude at the moment: I’ve coded exactly as much as I need for the moment. There are places you could feed it bad input and break its assumptions. It automatically creates plural versions of your added units, adding ‘es’ if it ends in ‘s’, otherwise adding ‘s’. That obviously wouldn’t work with ‘activity’ (-> ‘activitys’), and can’t handle exceptions like ‘forum’ -> ‘fora’ or something. Rather than have an automatic pluralizer, I should be having the user explicitly specify when they register the unit… (All of the above is no longer accurate.)

A bigger problem is that when an exception is thrown I can’t currently just find what line of code went wrong. I throw an Error object (which includes file and line number info), but it points at the place inside the library that threw the exception, rather than at the failing invocation that caused the exception. Most implementations of Error provide some sort of stacktrace, so perhaps I can generate one and then turn it into a string that includes that stacktrace info… because when it comes out on my Firefox console I don’t get the stacktrace currently. Anyway.

You can see the current implementation (as of this writing) here (UPDATED), if you’re curious and/or masochistic (it does some magic with JS prototypes to do its job, and lacks any useful documentation/comments, though I plan to add some).

It’s written as one part of this game Gate Arena that I’ve been working on lately, but am rewriting to emphasize a more declarative style of expressing objects and logic and their relationships, to increase code reuse and the ease of adding new enemy types, etc. I plan to reuse the resulting engine for further games, increasing my flexibility for participation in game jams and whatnot.