resistor-color-trio: create exercise#1772
resistor-color-trio: create exercise#1772HuskyNator wants to merge 10 commits intoexercism:masterfrom HuskyNator:risistor-color-trio(#1750)
Conversation
Implement, with the example using enumeration.
Include resistor-color-trio
|
Not sure why these are conflicts... |
It seems that you also added some changes for the Resistor Color Duo exercise, which has already been merged. |
| private enum Color { | ||
| black, brown, red, orange, yellow, green, blue, violet, grey, white; | ||
| }; |
There was a problem hiding this comment.
Java enums should generally be in UPPER_SNAKE_CASE.
I think the API should actually ingest the enum which should be a public file of its own (Color.java).
There was a problem hiding this comment.
Does the Java track exercise a policy or a preference wrt. multiple files handed out?
There was a problem hiding this comment.
I do not know of a specific policy, but I know that there are exercises which do this: https://github.com/exercism/java/tree/master/exercises/dominoes/src/main/java
There is one reference to multiple file submissions in the POLICIES file though (which implies it is totally fine):
The first exercise in the track whose test suite mandates multiple solution files should be accompanied by a hints.md file reminding the practitioner that the CLI supports multiple file submissions.
| @@ -0,0 +1,5 @@ | |||
| class ResistorColorTrio { | |||
| String value(String[] colors) { | |||
There was a problem hiding this comment.
| String value(String[] colors) { | |
| String value(Color... colors) { |
This should really take the Color enum as input. It's a good setup for varargs.
There was a problem hiding this comment.
From the exercise I thought the idea behind the exercise was applying knowledge about enums. Thus predefining them might defeat the purpose.
Fairly honestly however, I have since almost fully forgotten how exercism works and/or why the entire project is set up like it is. My apologies.
| String[] input = { "orange", "orange", "black" }; | ||
| String expected = "33 ohms"; | ||
| String actual = resistorColorTrio.value(input); |
There was a problem hiding this comment.
| String[] input = { "orange", "orange", "black" }; | |
| String expected = "33 ohms"; | |
| String actual = resistorColorTrio.value(input); | |
| String expected = "33 ohms"; | |
| String actual = resistorColorTrio.value(Color.ORANGE, Color.ORANGE, Color.BLACK); |
Same throughout.
| int intValue = (10 * Color.valueOf(colors[0]).ordinal() + Color.valueOf(colors[1]).ordinal()) | ||
| * (int) Math.pow(10, Color.valueOf(colors[2]).ordinal()); | ||
| String stringValue; | ||
| if (intValue >= 1000) { | ||
| stringValue = String.valueOf(intValue / 1000) + " kiloohms"; | ||
| } else { | ||
| stringValue = String.valueOf(intValue) + " ohms"; | ||
| } | ||
| return stringValue; |
There was a problem hiding this comment.
The canonical implementation should probably include encoding more information into the Color enum. Might also want to consider another enum for the powers (like OHMS, KILOOHMS, ...). This solution only adds support for kiloohms and we can do better (I know the Kotlin version goes up to something like exaohms).
There was a problem hiding this comment.
The Haskell solution only goes to giga, but adds optional edge cases that the original exercise does not address, because functional programmers have an obsession with totality. The point is that while you could extend the range beyond giga, you could also do a lot of other things, or not.
There was a problem hiding this comment.
I suppose I am biased by having seen the Kotlin implementation of this exercise. IMO: we should go up to giga specifically since the exercise naturally produces gigaohms.
There was a problem hiding this comment.
Keeping it simple and as specific as possible seemed like a good option.
However, as per my other comment, i do not know if this is preferrable or not.
| private enum Color { | ||
| black, brown, red, orange, yellow, green, blue, violet, grey, white; | ||
| }; |
There was a problem hiding this comment.
Does the Java track exercise a policy or a preference wrt. multiple files handed out?
| int intValue = (10 * Color.valueOf(colors[0]).ordinal() + Color.valueOf(colors[1]).ordinal()) | ||
| * (int) Math.pow(10, Color.valueOf(colors[2]).ordinal()); | ||
| String stringValue; | ||
| if (intValue >= 1000) { | ||
| stringValue = String.valueOf(intValue / 1000) + " kiloohms"; | ||
| } else { | ||
| stringValue = String.valueOf(intValue) + " ohms"; | ||
| } | ||
| return stringValue; |
There was a problem hiding this comment.
The Haskell solution only goes to giga, but adds optional edge cases that the original exercise does not address, because functional programmers have an obsession with totality. The point is that while you could extend the range beyond giga, you could also do a lot of other things, or not.
|
@HuskyNator - are you still working on this PR? |
|
Yes sorry, Ive been quite bussy |
- upper snake case for enum - typo & simplification in test
Closes #1750
Reviewer Resources:
Track Policies