> 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 ?
First preconditions in eiffel have different level of execution you can completely disable them. Once the new compiler is in pharo and the default compiler we could do really cool on the fly recompilation and have a large range of choices. Then we can use preconditions to generate tests or as one of my friend did in eiffel and java generate tests that you trash after and enhance the robustness of the preconditions. I read the PhD of benoit baudry and once you read the conclusions and the results it is clear that preconditions have really good properties. Now we have to be smart enough to understand how we can take advantage of them in our setup. > 2) Readability: 3 lines of assertions for two lines of code is too > much to my taste. > Opinions may vary... It is a question of balance. Not everything is black or white. > 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). Again it is a question of balance and usage. We should decouple the tool from its usage. I think that we should learn from it. > I think Smalltalk quality is based on a completly different plane You mean not checkable documentation, absence of documentation, lack of static typing to document (because what would be good is to have a pluggable type system) _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
