Beta
Typed Objects
Loading description...
Algorithms
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.
This test in the test fixture assumes that every key is already set in the typed object before any assignment, which is different from the default behaviour of object (obviously, keys that are not set yet will not appear in
Object.keys
). This behaviour is not mentioned anywhere, and probably should be changed.a = b
should returna
( with its new value ) in JS. The reference solution doesn't seem to do this and I haven't checked if this is tested. Existing programs sometimes rely on this; it is not good practice to returnundefined
for this expression even if the side effect is handled correctly.Not sure how this would be possible, I tried to return the expression itself but that doesn't work.
Also,
a = b
returnsb
and notundefined
, or am I missing something?The value it returns is
b
, of course, but the reference it returns isa
. This matters ifa
is an object or a property of one.I can't tell you offhand why your solution isn't working; possibly the mechanism is different within a setter. But, frankly, I think that's your problem. If I knew, I would gladly tell you, but seeing as I don't, I'm not making your problem mine. Both Alex' and my solution handle this correctly, as far as I can see, so it's not impossible.
Consider describing the values in the configuration object as contructors ( because they, at least mostly, are ). And consider specifying untyped values by having their constructor be
undefined
( that seems more appropriate thannull
) instead of some arbitrary string instance."you should use
Array.of
" is just wrong. You can, but there are other ( simpler ) methods as well. Especially given your estimated rank, I'd skip the whole tip and let solver figure it out.Thanks for your feedback, I implemented it the way you suggested, although I used
null
instead ofundefined
.This explicitly requires
Array(1)
to result in[ <1 empty value> ]
instead of[ 1 ]
. The wording here should be just a little less positive and unambiguous; the required value should be an instance of the constructor containing the new value. The current specs and example are therefore inconsistent ( and the spec should be leading, which it isn't ).Fixed the description.
Actually, I like the concept.
But not having random tests is an automatic downvote for me.
Consider unpublishing the kata back to
Draft
while you add random tests.unpublished
Added random tests.
Description lacks actual specifications. Examples are not specifications.
Description is also missing what the initial values in a new
typeObject
should be.Fixed.
Description still doesn't specify what the initial values in a new
typedObject
shall ( or can ) be.Is using code really the best way to explain this kata? :V I think it should have a(t least a) short description to explain what's going on.
No, using code is not the best way to explain a kata.
No tests where a new value is set in the typed object.
Edit: at least, I assume
typedObject
should support such behavior, otherwise why would the value be assigned instead of being provided as an additional function argument in the first place.Implemented that. You can check the new description.
Object.keys(typed).forEach((key) => (typed[key] = 1));
this implies a lot of things and is never talked about in the description. Meaning the user cannot actually know what the task is by reading the desciption.
cheers
Updated the test case (and description) to make it clearer.
I have a question, why does the example test not update? I updated it in the editor and saved it, but the changes aren't public.
Nvm, I figured it out.
examples with this in the description would be cool too:
Added.
No random tests. "I'll fix it later" is not a reason for resolving issues.
Added them.
PascalCase is used for naming classes, for functions use camelCase.
Changed. The reason I used PascalCase was because it pretty much is a class since it returns one, but I see why it may be confusing.
You didn't change the initial code.
The
"non-typed"
thing is not tested.Fixed.
No random tests.
I have thought about adding random tests but I can't find a way in which it would make sense.
Nevermind, I just realized that no random tests makes cheating extremely easy. Will add them later.