Derk-Jan Karrenbeld

Sad. That's already pretty much as optimal as we can get. I'll figure out if there is a way to still test each and every name...

Hi there! 5 hours ago I pushed an update to this exercise. Due to #387 it won't sync to the website just yet, but can you check if these tests...

It's intentionally no longer a Map. You _can_ use a Map internally if you like, but the test suite doesn't impose it. The method names have also intentionally be renamed...

Eh. I'm in the middle. I totally see the value in persisting the data types as is. I do really like to keep these new methods names (because of the...

I think this is a good change. Can you also propose this change in https://github.com/exercism/problem-specifications first? I expected other tracks benefitting from this addition as well.

It took a _very_ long time, but as soon as @ErikSchierboom is back from xmas holiday, the problem-spec PR will be merged, which means we can _finally_ merge this as...

The fact that they're official makes me inclined to just enforce, at least as a warning, maybe even as error. As far as I can tell from the links that...

If it will error later, make it an error now. It will still compile but show up as error which is a nice intermediary

Yeah. I think it makes sense. My argument is always: if it's official, there will be tooling. If there's tooling, there's official dependency on it following the guidelines. Therefore enforce...

It's a lot like react hooks; I like how it looks. I think it's fine to do the implementation like that @peerreynders . Are you up for implementing that exercise?