Serge Stinckwich a écrit :
Yes, you are right. Oscar answers with a more explicit error message,
which seems better also to me.
I asked to myself whether i should assert preconditions in my code, and
decided not to do so for several reasons.
1) I generally avoid preconditions in Smalltalk but in a few protected
places, because it's like locking the code against future extensions.
2) because the pre-condition is not needed to solve MethodFinder problem
3) because i cannot find a good reason to put a precondition
specifically in this method and not into any other
4) because i can find good reasons to not put preconditions uniformely
in the Kernel: it spoils both efficiency and extensibility - see 1)
(printing numbers in tight loops is not that rare).
5) because in Smalltalk violated preconditions are rarely fatal
6) because the limitation is trivial and any user with decent culture
should find it quickly with the Debugger
7) because even a kid opening the Debugger would maybe have a great
lesson initiated on arithmetic with proper guiding (agree, not by himself)
8) because Oscar preconditions are not enough, he didn't handle this (15
printStringBase: Float pi)... Even if he checks for an Integer, did you
try (100000000000 printStringBase: 123456789). Tell me, where to stop
preconditions?
Of course, on this specific example, maybe i'm just wrong and your
opinion may diverge.
A system made for learners should better have explicit rules.
Feel free to add a precondition in the code, that's what MIT is for!
or just add a comment about base expectations...
I won't change a bit.
Cheers
Nicolas
Locked
