two-bucket: Do not specify any types in description #990
Conversation
The description currently specifies that buckets are represented, in both the input and the output, as strings. This seems overly constraining. Consider those tracks that wish to represent these buckets as variants of a tagged union or of an enum for the purpose of better type safety. These tracks have these options in order to do so: * Accept the problem-specifications README as is, but act in contravention of it. But it is confusing if the README contradicts the tests. * Create a custom description.md. But this is a little unfortunate because only two lines need to change, and it adds extra maintenance burden to have to maintain the custom description.md. Consider that if this description.md changes, the changes will probably need to be copied to each custom description.md * Add to .meta/hints.md saying something to the effect of "ha ha ignore the above text about using Strings, we're using tagged unions / enums" so that this will be appended to the description. But it seems too strange to have a README contradict itself. * Other solution I did not think of. Thus, it seems it is best to remove the specification of the buckets as a string so as to allow the flexibility. For the purpose of consistency, all other types have been removed as well, otherwise it would invite (very reasonable) questions about why all inputs/outputs except the buckets have types given. It is surmised that this leads to no real loss, because it should be obvious that sizes, number of moves, and number of liters are all numeric values. Closes #989 by mutual exclusion.
|
Tracks that implemented it and thus are more likely to care (of course, I welcome others to care as well!): http://x.exercism.io/problems/two-bucket ["csharp","ecmascript","fsharp","javascript","python","ruby"] |
|
.... eh? https://github.com/exercism/csharp/blob/master/exercises/two-bucket/TwoBucketTest.cs and https://github.com/exercism/fsharp/blob/master/exercises/two-bucket/TwoBucketTest.fs already use a enum / discriminated union. So y'all have already been taking my first listed option (take the README as-is and do something different). Has anyone complained about that, by any chance? |
|
By the way, you don't care why I care, but if you did care, then I would tell you that the Rust track is going to have an implementation of it soon because of exercism/rust#375, so it is important to the track |
Nope, nobody did. But it is one of the harder exercises, so it is at a point where few people arrive at. |
|
I'm not in a hurry, I'll give it 48+1 more hours, bringing it to a total of 96 since submission. I'll speed it up if I get an approve from all implementing tracks, but no hurry at all. |
|
FWIW, I think this is a better option than #989. |
The description currently specifies that buckets are represented, in
both the input and the output, as strings.
This seems overly constraining. Consider those tracks that wish to
represent these buckets as variants of a tagged union or of an enum for
the purpose of better type safety. These tracks have these options in
order to do so:
contravention of it. But it is confusing if the README contradicts the
tests.
because only two lines need to change, and it adds extra maintenance
burden to have to maintain the custom description.md. Consider that if
this description.md changes, the changes will probably need to be
copied to each custom description.md
the above text about using Strings, we're using tagged unions / enums"
so that this will be appended to the description. But it seems too
strange to have a README contradict itself.
Thus, it seems it is best to remove the specification of the buckets as
a string so as to allow the flexibility.
For the purpose of consistency, all other types have been removed as
well, otherwise it would invite (very reasonable) questions about why
all inputs/outputs except the buckets have types given.
It is surmised that this leads to no real loss, because it should be
obvious that sizes, number of moves, and number of liters are all
numeric values.
Closes #989 by mutual exclusion.