> The only problem I see (maybe I am wrong) here is that there are already a > lot of implementors of isAbstract. For example, those used in Sunit. So, if > you add this method to Behavior, there will be a lot of non-intentional > overrides.
As Mariano writes, most applications implement a message #isAbstract themselves with the exact semantics they require. I don't think a generic message in Behavior is really useful, especially if it is not used by the core system. Interesting in this context is how the Refactoring Engine determines if a class is abstract: "Smalltalk doesn't have any language feature that denotes an abstract class like C++ or Java. As a result, we check for a couple things when looking for an abstract class. If the class contains any method that sends #subclassResponsibility, the we consider the class as abstract. A method that sends subclassResponsibility signifies that users should override this method in every subclass to have all the class' functionality to work. Another check we use to determine if a class is abstract is to look for references to the class. If the class is not referenced then the class is considered to be abstract, since there is no way to create an instance of the class." [http://st-www.cs.illinois.edu/users/brant/Refactory/] Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
