Updated tests to use assertDeepEquals

I realized that in the start of the description I defined an elemental word as "any string of letters formed by the concatenation of one or more element symbols" (key words being "one ore more"). I have updated the description to include this wording in the guidelines. I think, taking this definition into account, [] would be the natural return value for elementalForms('').

Cool! I made this so long ago I always forget it's still here haha. Your translation looks solid. My thinking with the empty strings was that if a word (whether it's empty or not) has no "elemental forms", then an array containing no forms (i.e. an empty array) would be the natural return value. I do understand that the "empty" combination could form the empty string though. Maybe I will update the description so that an elemental word is defined by being able to be formed with a non-empty combination of symbols.

Recursion is definitely a possible solution, and probably the more common one. I would check if you're unnecesarily recursively calling your function too many times. You don't only need to use recursion ;)

.

When twigs are chopped off, are "full" twigs (those with 10 leaves) prioritized to be chopped off first? Same for branches and trunks?

For instance if I chop one leaf off a DecaTree, and then I chop one twig off, I could either be left with 989 leaves left, or 990 leaves left, depending on whether or not I chopped off the twig that already had a leaf chopped off.

The Lift never changes direction until there are no more people wanting to get on/off in the direction it is already travelling"

Confused myself for a while because my interpretation of this was "until there are no more people wanting to travel in the direction it is already travelling." Then I finally realized it actually means "until there are no more people wanting to get on or off of a floor that the lift is currently approaching." :P

Ah, sorry, my "solution" was to have the code result in an error condition (infinite recursion) if .length is used anywhere in .size()'s call stack. It was not meant to detect whenever .length is being used and automatically have the tests fail (I assume that's what you were doing? - per "false positive").

I used receiver to "return to the proxy" when calling .size() (i.e. it will go through the get trap again) -- I guess it doesn't really matter in this case whether you do target.size() or receiver.size().

Edit: actually I think receiver is necessary, because if you call .size() directly on the target, then any .length access won't pass through the get trap.

Does the above not work? If so, what is the behavior you're seeing vs. your expected behavior?

Cool! I still haven't 100% wrapped my head around cryptocurrencies & blockchain stuff but it's really interesting!

ahh, I neglected the documentation and implemented the conversion myself :P

Nice kata

I wouldn't say that the class syntax is to be avoided; in fact I personally prefer it, and I think the JS community as a whole is moving in that direction as well. I think the big thing about it is that you are correct in saying it was introduced to make people comfortable -- specifically people familiar with class-based OOP. And underneath the hood, there's none of that in JS -- it's still all prototypal inheritance.

So the big gotcha is that even though we have the keyword class, there's still no such thing as actual classes in JS. Which, understandably, leads to a huge amount of confusion, especially for people who don't yet understand what class-based vs. prototype-based even means. So it's this thing introduced to make people more comfortable, which quite obviously made other people confused/uncomfortable, but I think it's gaining traction and you'll see it used more and more often, so long as we all keep understanding/teaching that JS is strictly prototypal.

I really like this kata a lot, except for the single part where the selector parts have to be given in the correct order by the user. Personally, I think you should be able to provide the class with the parts in any order, and ensure that the implementation stringifies everything in the correct order, rather than throwing an error if the user supplies a pseudo-element before a pseudo-class for example. Would that not make for a more versatile, user-friendly API?

As for everything else, it is really good. I think the error on the multiple elements, ids, or pseudo-elements provided is OK, that actually makes sense because if it happens it's probably something the user of the class didn't mean to do. The tests are good -- I like how the implementation is left up to the codewarrior and you just test the end result. You might want to create a few random tests as well.

Anyway, all in all it seems really good. I know the ordering thing isn't necessarily a problem with the kata itself, it's just a suggestion. I feel like it could be a good exercise in deciding where throwing an error is really necessary. :)