On 8 October 2010 00:59, Johan Fabry <[email protected]> wrote: > > On 07 Oct 2010, at 17:04, Igor Stasenko wrote: > >> On 7 October 2010 23:39, Johan Fabry <[email protected]> wrote: >>> Always fun when you want to show the students that everything can be >>> changed in Smalltalk ... >>> Inclusive the behavior of Integer>>+ >>> Inclusive when the current behavior does strange things with the second >>> argument when it is not a number (instead of simply throwing an error), e.g >>> what happens in 1 + 'foo' >>> Inclusive when you are debugging said expression. >>> >>> Apparantly that was too much to ask :-( Hard crash of the image :-( :-( >>> >>> Reported as issue http://code.google.com/p/pharo/issues/detail?id=3072 >>> >> its not very good idea to replace >> ^ aNumber adaptToInteger: self andSend: #+ >> >> with >> ^ self error: 'boo' >> >> because many parts of system relies on 'silent' type coercion. > > Well, I was not going to use the image for anything else after that ;-) > >> I didn't experienced the hard crash in pharo image. >> What i got instead, is an error, printed in emergency console >> >> saying that it unable to handle the system error .. > > Ok I guess that my concept of a hard crash is a bit softer than yours. > >> the culprit is in ImageMorph>>image: >> while somehow relying on correct behavior of Integer>>+ > > The question is why is laying out doing this with non-integers? Screens work > with pixels so I did not expect that. You are right that I had to have > thought about coercion of others, but I did not expect that to happen at that > point... Next time I will be more careful ... > Its a good question why its there. But of course, i wouldn't never expect from system to keep working stable & normally, when you changing something as basic as Integer>>+.
But there is a bright side: such things could be used to detect low-quality code (or code, which intentionally doing coercions ;)... For instance, i often type: 100/200 if you evaluate that, you'll get a Fraction as result: (1/2) but i want the answer to be Float, so i type: 100/200 asFloat and here, when you change the Integer>>#/ to throw error instead of coercing receiver, i won't be able to use it anymore, and will be forced to write: 100 asFloat / 200 asFloat > -- > Johan Fabry > [email protected] - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > _______________________________________________ > Pharo-users mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-users mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
