Sorry - just saw this comment.. I know it was from a while back but it's interesting, so I thought I would respond. I'm pretty sure .shift() on arrays is O(constant)... that said, after looking it up I've found that it does seem to perform a lot slower than indexing... (see here: http://jsperf.com/some-array-reading-comparisons/6 ) as you would expect, because it's mutating the array instead of just reading values from it... whether or not it's a whole/partial O() class slower, I'm not sure...(anyone know?)

I also learned something else really interesting while looking this up: Apparently .pop() is way way faster than .shift() (see: http://jsperf.com/popvsshift ) . Makes sense if you think about it...but weird, right? I always sort of treated the two as roughly equivalent from a performance standpoint.

I'm glad you pointed this out, because I use the queue/stack ops on arrays all the time. For writing clean/readable code, I still like it because it keeps the "stuff" you are working on in the "right place"... I don't know if I'm expressing that correctly, but to me it just seems easier to visualize and test/debug those than integer indexes into arrays... this stuff is definitely worth keeping in mind, though, if you start running into performance hotspots... Thanks for bringing it up.

Fun kata.

Nice, clean and easy to read. +1

Sorry for the confusion there and thanks for the spot - I fixed the label on that test case.

Oh man...look a it on Opera... 99% slower... jeez.

Got CW on http://webplatformdaily.org/#September27th2013 today.

This one looks really fun. I'm hoping I'll have some freetime to take a crack at it this weekend.

One other drawback I just thought of is JSON serialization... one of the best features of JS is that you can serialize/deserialize from JSON (with everything but functions) and have the objects "do the same thing" in a sort of 'idempotent' way... custom getters and setters kind of break that b/c they won't serialize with their getters and setters intact... not a dealbreaker by any means, but just something to keep in mind when you are looking at the structure of your code.

The purpose of that was to elucidate that the object should otherwise just act like a "normal" object that you can assign keys and values to, etc, w.r.t. everything but "temperature". I can just take it out, though.

A couple more on Kata testing practices:

1. In te failure messages for your tests, be as descriptive as possible about what you were expecting and (where applicable) what you got instead... It is frustrating for students to be validating their solution and just get an "error" message with no description of why their test case didn't pass.
2. If you expect vars to be closed within certain objects, be sure to test global scope to ensure that they weren't just tacked on to global.

Updated the test cases, too.

@neuro, thanks for the JS perf link - I was hoping to find something just like that.

Beyond the performance stuff, are there any reasons it might be dangerous to have "hidden side effects" tied to getting and setting properties on an object? ... I know for a lot of people, the "best" thing about JS is the "no BS" way that objects work... do you think custom getters/setters dilute that, or just strengthen it? (I probably would come down on the side of "makes it better", just curious what others think...)