6 kyu
Custom Setters and Getters
1,098 of 1,122bkimmel
Loading description...
Fundamentals
Object-oriented Programming
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.
Node v12 should be used enabled along with its appropiate assertion tools (Mocha + Chai).
No random test
No sample tests.
Kind of weird having getters and setters for temperature, but not for archive...
i get stuck here
yees,, i solved
help a lot to me
I can't understand why the 5th test fail with "TypeError: Cannot redefine property: temperature". Spend time googling but with no result.
This seems silly to me. My code works just fine when I run it. When I run it against the tests, I get the following: Changed temp 3 times, expected this.getArchive to return 3 items. Got 2
This is after adding JSON.stringify to the result of getArchive. If I don't use JSON.stringify, it complains that it expected 3 items, but got 0.
console, though, when executing there, returns all 3 objects just fine
This comment has been hidden.
What is 'x' in your setter?
Maybe I've missed something, but why are there no sample tests? I don't quite get how to test if the archive getter results are valid.
This comment has been hidden.
This comment has been hidden.
Actually maybe too helpful
Assigning a getter should be mentioned in the instructions otherwise one can get stuck if (s)he has implemented the code correctly
Hi, when I submited my solution, I got first 3 tests passed, but failed at 4th. What is 4th test?
The fourth test test if the date objects are being set up correctly.
Hi, is there an issue with one of the tests? The test that changes the temperature 4 times is saying my code returns 7 entries, yet I cannot re-produce this myself. If I change the temperature 4 times in my console I get 4 entries in the Archive...
Why do I get the stack_overflow error when i try to run my code?
stack_overflow: Maximum call stack size exceeded
My bad, I was calling the setter from within the setter. :(
The instructions don't say anything about requiring a getter for temperature. But one is required in order to submit successfully.
The instructions should definitely mention something about requiring to implement a getter. Even better would be to have the example in the description use the getter as well.
Agree, but is the problem is not "if you don't provide a getter we won't accept your submit" but "if you don't provide a getter your method won't work". Fire up your console and test it for yourself. This is indeed unexpected.
Same, it executed without a hitch in my console without a getter. But when submitting the solution, I got:
Expected {}.temperature == 21, got undefined
Including the getter solved it.
Is there value in having the someRandomProperty example? It seems to create noise when understanding the requirements, without having any purpose for being there. Other than that it seems like this is about ready to come out of beta.
The purpose of that was to elucidate that the object should otherwise just act like a "normal" object that you can assign keys and values to, etc, w.r.t. everything but "temperature". I can just take it out, though.
Discussion topic: Now that you've made it through the kata and you know how the custom getters/setters work, what do you think about their use in practice? I've heard some people say that they belong in JS's "evil" basket along with eval() ... and other people use them frequently. Browser support for these is "uneven" at best, as I understand it... One drawback that I've heard of is that they really hit your performance hard.. on the other hand, being able to "tuck" functions into normal object reads and writes gives you the power to do some interesting things like we did in the kata that would otherwise not be possible in JS...
This is a great kata, and the discussion could be interesting as well. I have never liked the look and feel of code that requires passing a function parameter to simply set some value. Defining properties allows me to make use of the more 'natural' assignment operator (i.e. "=" ).
I think that both the convenience and power of actual getters/setters is too good to ignore. Browser support is iffy but it seems like everyone is getting up to speed rather quickly. As for the performance hit it doesn't seem to be too bad compared to function calls and will likely get optimized in the future.
Of course, as with everything in the world of JS, if you're doing something super performance critical or will be called a lot, it might be better to stick to other methods.
@neuro, thanks for the JS perf link - I was hoping to find something just like that.
Beyond the performance stuff, are there any reasons it might be dangerous to have "hidden side effects" tied to getting and setting properties on an object? ... I know for a lot of people, the "best" thing about JS is the "no BS" way that objects work... do you think custom getters/setters dilute that, or just strengthen it? (I probably would come down on the side of "makes it better", just curious what others think...)
This comment has been hidden.
One other drawback I just thought of is JSON serialization... one of the best features of JS is that you can serialize/deserialize from JSON (with everything but functions) and have the objects "do the same thing" in a sort of 'idempotent' way... custom getters and setters kind of break that b/c they won't serialize with their getters and setters intact... not a dealbreaker by any means, but just something to keep in mind when you are looking at the structure of your code.
Bkimmel, your Kata here inspired me to dig deeper into getters and setters. Let me know what you think of my new kata: http://www.codewars.com/dojo/katas/5240e3a98d333f81950001ad/discuss