Timeline for First Hangman Game. Need Honest Opinion
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 11, 2022 at 18:30 | comment | added | Richard |
@FMc thanks for the thoughts! FYI I'd probably make them properties in this case (like you), but also realize at this level it's all semantic really and likely no hard/fast/objective/one-size-fits-all rules/guidance - meaning do you reference the value by obj.x or obj.x() is essentially the only difference.
|
|
| Jan 11, 2022 at 18:16 | comment | added | FMc | @Richard In my experience, simple distinctions like thing/action or X/getX don't take you very far in the real world of building complex software. So you still have to fall back on more holistic/contextual judgements, and quite often the decisions end up being compromises among valid but competing general principles. In this case, my judgement is best summarized by the comment above starting with "the object itself is designed as an immutable data bundle ...". | |
| Jan 11, 2022 at 17:53 | comment | added | Richard |
@FMc @ades Is another way to look at it to say a 'property' is a 'thing' - so a noun, while anything else is an 'action', so is a verb? This maps to the difference b/w X and getX. The fact that, under the hood, a 'property' may, or may not, be stored as an object attribute, or calculated on the fly, isn't relevant. ...do you think this kind of thinking valid has any merit?
|
|
| Jan 9, 2022 at 17:47 | comment | added | FMc | @ades I guess I don't find the is-it-trivial distinction very clarifying. A better one might be is-it-expensive: in that case, using a property is ill advised. To my eye, all of the properties are trivial and non-expensive. They also all seem purely derived from the core information. In fact, one could just as easily compute them in advance and store them as attributes. The object itself is designed as an immutable data bundle (that also knows how to generate then next state), so delivering everything as quasi-attributes (ie properties) seems consistent with that vision. But opinions vary. | |
| Jan 9, 2022 at 17:09 | comment | added | ades |
Another way to try and describe the first example @FMc: x is a property but getX isn't. So for many things you can choose if you want them to be properties or not (through phrasing), which is where Google's recommendation/stance comes in handy; "is this trivial enough that we can get away with calling it an attribute without affecting readability"?
|
|
| Jan 9, 2022 at 17:04 | comment | added | ades |
Properties for me are for attributes/members. Displaying a word is a process, which is confusing to mix with the operations that you use for attributes. I'd wonder what was going on if I read a call that was GameState.display_word - I could see how GameState.current_word would be a property. That would be the behavioural deduction. If we instead use Google's "classifier", you could also argue that the operation that you perform isn't trivial enough; you have a conditional and you transform type. This one is less clear ("what is trivial"), but I think you get the point.
|
|
| Jan 9, 2022 at 16:58 | comment | added | FMc | @ades "Things like outcome and display_word should not be properties". I would/could be more convinced if you gave a reason. I say that it a non-snarky way. | |
| Jan 9, 2022 at 16:41 | comment | added | ades |
I think having is_finished as a property makes sense, but things like outcome and display_word should not be properties. I think you can take two routes - either follow google's style guide and define properties by how trivial the operation is, or try to deduce according to behaviour. And in either of those cases I don't think all those methods should be properties.
|
|
| Jan 9, 2022 at 16:31 | comment | added | FMc |
@ades Because the alternatives are worse. Consider lives as an example. (1) Option 1: store it as an attribute. Bad idea, because lives is purely derived from word and prior guesses. If you store lives separately, you have to manage correlated data, which is error prone. (2) Option 2: provide lives via a regular method. That works alright, but it does force the user to type gs.lives() rather than gs.lives.
|
|
| Jan 9, 2022 at 14:46 | comment | added | ades | Why are you declaring basically all of the GameState methods as properties? This doesn't make much sense to me. | |
| Jan 9, 2022 at 0:45 | history | edited | FMc | CC BY-SA 4.0 |
added 1 character in body
|
| Jan 8, 2022 at 21:29 | history | edited | FMc | CC BY-SA 4.0 |
added 89 characters in body
|
| Jan 8, 2022 at 21:23 | history | answered | FMc | CC BY-SA 4.0 |