Stéphane Ducasse wrote: > On Dec 23, 2008, at 11:19 PM, Keith Hodges wrote: > > >> Stéphane Ducasse wrote: >> >>> No it should follow well specified rules. >>> >> Ultimately the compiler is not really compiling smalltalk, it is >> compiling some primitive concepts that Behaviour and friends turn in >> to >> smalltalk by virtue of their implementation. There is nothing stopping >> anyone one defining another language with entirely different >> conventions. So the compiler should not enforce smalltalk rules. If >> Behaviour/ClassDescription wants to enforce some rules then that is >> Behaviour's business and it should be overrideable. >> > > sorry I do not buy that. Do you know why Smalltalk 76 did not work > because classes could change their syntax. > That sounds like a great idea to me. Ian's work on fonc also allows that kind of thing.
Smalltalk is the simplest language with the least number of rules, and least number of exceptions to the rules. This is what makes Smalltalk stand out and what makes it powerful. So why do you think it is virtuous to add rules and add exceptions to rules. I always thought these arbitrary conventions were a pain, and never saw the point in them at all. For example if I implement a class with a class variable, Foo, and I refactor it because I realise that I need it per subclass, I move it into a class instance var, I end up having to change all the code from Foo to foo. The rule about globals being uppercase is another one I have broken for what I think is a good reason: defining null := Null default. I always find a reason to break conventions. For example in Sake/Packages we break the convention of method names begining with a lowercase letter, simply for readability. So I simply know in advance that any such hard restriction is going to become a problem at some point. If it can be enshrouded as a social convention then that is good enough, there is no need for the compiler to roll over and die. Keith _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
