refinements: removed from individual cases

[ajwann]

fixes #645

[ajwann]

I think it's best if we still use the refinement within ExerciseCase. If we don't, we will have to define two separate underscore methods, one for Fixnum and one for String, or define a single underscore method that switches on the type of the argument. Personally I strongly dislike the latter option.

[Insti]

I agree that switching on type is undesirable.

[Insti]

Getting rid of the refinements in the Case classes is good 👍 and I think what you have here is mergable.

I'm not sure continuing to use the function with refinements the way we are here is a good idea. Underscoring a string and underscoring an Integer are two fundamentally different operations performed for different reasons, yet they are called using the same function.

Perhaps two different methods is the right way to go, but naming them based on why rather than what.

@kotp had some thoughts about this (that I can't find to link to right now.)

Edit: What about literal(number) and underscore(string)?

[ajwann]

I agree that string underscore and integer underscore are very different operations, and I'm in favor of creating the literal(number) and underscore(string) methods.

[Insti]

I'm in favor of creating the literal(number) and underscore(string) methods.

Is this something you want to do as part of this PR?

[ajwann]

@Insti sure, no problem! I can make the change right now actually.

[ajwann]

@Insti I think this is good to, but let me know if you want any more changes.

[Insti]

Looks good, thanks @ajwann