Serge Stinckwich a écrit :
> nicolas cellier a écrit :
>>
>> Good find Oscar but already on Mantis, see 
>> http://bugs.squeak.org/view.php?id=6724
>> See also http://bugs.squeak.org/view.php?id=6710 and search 
>> MethodFinder on Mantis.
> 
> 
> With your patch, Method Finder works but :
> 
> 1 printStringBase: 1 reply a divide by zero with is a bit strange ...
> 
> -- 

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