However, would you really try to apply this kind of rule to the whole Smalltalk Kernel ? That would be interesting because these rules have a cost in - speed - readability of code - extensibility of code 1) Speed: every little method calls a little method, calls a little method ... At which level do you put the tests ? How many times is the same test applied thru the call chain ? 2) Readability: 3 lines of assertions for two lines of code is too much to my taste. Opinions may vary... 3) Extensibility of code: you'll have to care not to restrict future extensions too much. Pushed to the limits, this ressembles static typing (fortunately we shall use message isInteger rather than isKindOf: Integer). I think Smalltalk quality is based on a completly different plane Nicolas 2009/10/16 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Yes and this is really important because pre and post are valuable for software engineering quality promotion.
Stef
On Oct 16, 2009, at 1:55 AM, csrabak@bol.com.br wrote:
Em 15/10/2009 04:50,  Stéphane Ducasse <stephane.ducasse@inria.fr> escreveu:
I see. Â Eiffel ideas cross breeding Pharo Smalltalk!
  The idea  is that one day or  later we will have  to think about   the benefit  of pre  and post condition.  So assert:  in object   makes a lot of sense.
  Now  indeed it  would be  good that  all the  tests  use assert:   without block and use should: for that case.
  Stef On Oct 15, 2009, at 3:55 AM, csrabak@bol.com.br wrote:
I don't either,  but I find strange the  complete hierarchy of classes of  Pharo having  a method assert:  available. Perhaps I'm blindfolded  and Pharo and  Squeak have found a  wider use for assertions?
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project