Retired
JavaScript Built in Types: Arrays, Strings, Sets (retired)
Loading description...
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Why the unused, confusing functionality ( delimeter ) in the example solution?
This is a 7 kyu kata; beginners might look up your solution to see how it should canonically be done, it should be as clean, simple and efficient as you can make it.
That's the idea. It gets you thinking about how you might possibly extend the functionality into something better while maintaining backwards compatability. It's food for thought essentially.
Or it just confuses the H3ll out of 7 kyu solvers who don't yet even know what default arguments are, but can convert between strings, arrays, and sets.
I remain unconvinced, but it's your kata.
Eh you've sold me. I'll take it out.
99 more random tests wouldn't hurt.
Using the same input for six assertions at a time would mean you only need two reference solutions ( generate a string, calculate the corresponding array and set, use those values as inputs and expected outputs ).
The
it
-headers of the random tests could show values in a nicer way. UseJSON.stringify
for strings and arrays, and maybe mock up something custom to replicate the output of console.log(set)?Use
strictEqual
for strings.args
is just a wrapper forArray.from
. Also, it's just unnecessary if you pass a single string instead of a list of chars.This comment has been hidden.
This comment has been hidden.
Extending prototypes should be done with
Object.defineProperty
, otherwise, you'll have enumerable properties on your prototype, which will give unexpected results withfor .. in
.The kata sould specify, and test for, non-enumerability.
Thats a good point. Do you think I should change it in the initial solution as well or let people figure it out on their own?
The rest of the kata isn't difficult enough to make people figure it out on their own, I think.
Giving it to them for free is most useful if you explain why it's necessary though.
Okay. I added parts to the description, solution, and tests related to nonenumerability. I also threw in at least 99 random tests.