Debatable, but to prevent prematurated approval:

Isn't the kata just another dup of the many calculators kata? (I'm specifically thinking about the C# one, which uses some similar concepts)

https://www.codewars.com/kata/reviews/5859b36dd3ed274f4e000692/groups/6450829210b72e000120b4d0

Kata author: it is not funny to randomly ban regex when your description also defines things in terms of regular expressions. In addition, this adds nothing to the task, besides making it more a nuisance. (If you think this adds "difficulty" to the task, then your kata is objectively bad. Find something better to author on.)

One can also argue that if you don't want people to use regex, then don't author the kata in Java and JS where regex is part of the language built-in. Author the kata in C++ or something instead.

Description contains a lot of wild tangents of the kata author contemplating about random stuff rather than a clear description of what is needed.

JS version is still stuck at Node v8.

Also, JS version doesn't have sample tests.

Since this is a duplicate (as mentioned before) it should probably be retired.

I've just published updated version with 'IllegalArgumentException' as error signal, and portions of random tests.
One's else solution is strong enough to pass them.

These solutions are not the target of this kata: Integer.toString(a, 16), String.format("0x%X", a), Integer.toHexString(a)

Are these methods supposed to be forbidden, or does this message mean "these methods will not return the exact expected output"? If it's the former, it should be enforced. If it's the latter, then mentioning this is pointless, and gives away the solution.

No sample tests.

• no random tests
• almost no tests at all
• underspecified (mutation of the input? yes? no?)
• not talking about the fact that builtins are accessible...

Maybe add the import for them ;)

Hi,

The setup of the task is absolutely awful :/
Mostly:

• data structures makes no sense compared to the actual task
• some of the provided methods aren't the correct choice for the current setup
• no random tests
• some parts of the contract aren't correctly/fully described

To go deeper into the problems:

• the list of songs in the library shouldn't be a list at all but at the very least a set (but rather a map, see below)
• the Song class is lacking:
  • overrides for equals and hashCode.
  • methods that make sense for the current task: increment/decrement (even better if returninng this). Not the full boiler plate with 2 methods requiring the user to compute on his side the correct number. You're breaking encaspulation, here (well, let's rather say you chose a very poor design...). But don't bother with that because...:
  • the number of plays shouldn't be handled by the song instance itself. It's not related to the song only, but to the song in a particular context/library. Meaning that the correct design for the task is to use a Map<Song,Integer> for the library. Moreover, this has the advantage to avoid the need to mutate the Song instances.
• the contract for remove isn't explained in the description (-> remove one play, not the song... / EDIT: btw, what's the point of removing one play ??)
• the method giving a list of songs is either useless or not tested, and in any cases, hasn't any specification for now.
• description is a total mess (mostly because of the last markdown update) => needs to be cleaned up
• separators for the Library.toString method aren't explained: I had to look at the sample tests to know about it (might just be they aren't visible for now, because of the previous point?)

Suggestions:

• describe the contract of the behavior of the library more precisely, and the specifications of the methods you'll use for your tests
• let the user chose the internal representation, but don't provide a bad setup in the first place: less is better, here. And remove the comment about not modifying the existing code (I rewrote most of it ;p )
• if you don't provide equals and hashCode for the Song class, don't provide the toString one either.
• remove the getSongList method unless you give a precise sepcification for it (and don't ask for a list with duplicates, unless you add requirements for the order inwhich the songs are played. But then, it's a complete new task...)

Test Results:
 PolinomioShould
 randomTests
error when pol = [0, 0] expected:<[]> but was:<[0]>

test4
error when pol={}
Expected: is ""
     but: was "0"

Reference solution needs some fixes, I think...

Who approved this obvious duplicate?