I reopened it, it is currently in “Draft” state.
I reopened it, there is likely to be a little bit of churn for this, as there is activity regarding this exercise in Problem Specifications repository.
Please link this message in the PR if you have not done so yet.
Reopened for you, and it is still in Draft.
Couldn’t get GitHub to merge config.json from the previous commit so had to recreate the pull. Sigh.
New PR
Thanks @kotp .
This still registers as 0 commits, though. 472 has a commit, false alarm. (I might change the title/subject line to differentiate better for the pull request.)
I switched the stub to encourage use of muti-dispatch
aka function polymorphism. Of course you can solve it however – TMTOWTDI.
I wonder if it’s possible to allow solutions to take different paradigmatic approaches (ie accept a sub
or a method
) and so not limit approaches ?
We can definitely do that, the tests should test for results, not approaches.
To expand on that, and for the Proverb exercise specifically, the way that we can do that is to test for the song in its entirety to the point that a successful solution could be as simple as reading the text (golden text) that is the result of the song itself being printed out.
How you get there is fully, then, open to your propensity to explore.
We have tests like this, in effect, in the Ruby track for some of the “pattern string exercises” such as 99 bottles or 12 Days, and perhaps one other.
Why give either as a stub, and take more out of the stub to allow the student to solve it the way that they want to pursue?
I put in the multi approach because it adds some variety and awareness around a lesser used language feature.
I’m not sure what the test code should look like accepting different approaches. At the moment I’m only aware of how to test a single entry point. I will take a look at how other tracks do this – thanks for the pointers.
As an example of my confusion, imagine a function adding two numbers:
sub add ($a, $b) { $a + $b }
What if someone wanted to write an object-orientated approach like:
class Operation {
method add ($a, $b) { $a + $b }
}
In the first case we’d test the add
routine, but in the second approach we’d have to instantiate a class and call a method. We need a naming convention then or some other magic to know which class to instantiate unless we put the scaffolding onus onto the student:
class Operation {
method add ($a, $b) { $a + $b }
}
sub add ($a, $b) { Operation.add( $a, $b ) }
I suppose we could look to see if there is a function or method of the same name.
It may be that these lesser used items should be put into concept exercises, with the specifically tailored test to look for them being solved in that way in a concept exercise, rather than a practice exercise type setting, and then focus on one or the other.
The practice exercises should leave the implementation details alone, while testing results, instead, in my opinion.