I wonder whether if there is a difference between the general case, and the specific case which Stef suggests writing a test for Collection subclasses. If the behaviour of each concrete collection class is not going to change particularly quickly, i.e. the class hierarchy for Collection is fairly static most of the time, then you do not necessarily need a clever implementation of isAbstract for that subset of all classes in the system. You could just mark classes abstract or not as a method answering true or false. In the general case for Object>>isAbstract perhaps you need a reflective implementation. Along these lines, Dictionary is always going to be concrete, so why not implement isAbstract ^false. In this case I would prefer practicality over trying to work out if Dictionary, in this example, breaks some semantics of abstractness. Consider that someone adds an abstract method to Dictionary, if that method is not attempted to be invoked, i.e. it is not sent, from the POV of the client who does not know about the enhanced protocol, it is still concrete. Even though in a semantic check of abstractness it would fail. Do you want a test for abstractness to fail in this case? What is the real desire?
As for overriding #new, for example taking Singleton pattern implementations, I find that somewhat problematic in systems where it is very prevalent. One person's singleton, is not anothers - e.g. instantiating singletons to unit test them, where implicitly you break the pattern or have to send basicNew or some circumvention. I find it too restrictive to override new simply because it was thought at the time there would only ever be one instance. Now we're talking about abstractness not singletons, but I wonder if there is not a use for this in the sense of being a bit more liberal for future use. I can't think of one right now, perhaps when transitioning classes from concrete to abstract and vice versa, but there are plenty of singletons in systems that aren't strictly so- so there is some precedent for this being too restrictive. Mike On Mon, Oct 6, 2008 at 9:02 AM, Simon Kirk <[EMAIL PROTECTED]> wrote: > If the definition of abstraction is that one can't instantiate an instance > of the abstract class (I'm cribbing the definition of it here a bit from > Java/C#/etc where one can't instantiate abstract classes by restriction in > the language) then how about overriding #new on the class side with an > implementation which provides an exception from any send to #new on that > class and implement an #isAbstract that looks for that exception? > > That's of course assuming that non-instantiability is a desired behaviour > here. This could well be a bogus assumption on my part. > > Cheers, > Simon > > On 6 Oct 2008, at 07:18, Stéphane Ducasse wrote: > >> this is why there is a or in my expression and this is why I still would >> like to have a way to declare a class as abstract even if it >> does not have abstract methods. >> >> stef >> >> On Oct 5, 2008, at 11:34 PM, Alexandre Bergel wrote: >> >>> A class is said to be abstract if its not reasonable to instantiate it. >>> An abstract class may perfectly have no abstract method. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 5 Oct 2008, at 11:49, Stéphane Ducasse wrote: >>> >>>> I would really like to have a way to specify that a class is abstract. >>>> For example I would like to be able to write a test as follow >>>> >>>> self assert: (Collection allSubclasses reject: [:each >>>> each isAbstract ]) new isEmpty >>>> >>>> now saying that isAbstract is if a class has one method sending >>>> subclassResponsibility is not >>>> really good for me. >>>> >>>> >>>> May be we could have something like >>>> >>>> isAbstract >>>> >>>> ^ self declaredAsAbstract >>>> or: [ (self whichSelectorsReferToSymbol: >>>> #subclassResponsibility) isEmpty not] >>>> >>>> >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential to the > intended recipient(s) at the email address(es) to which it has been > addressed. It may not be disclosed to or used by anyone other than the > addressee(s), nor may it be copied in anyway. If received in error, please > contact the sender, then delete it from your system. Although this email and > attachments are believed to be free of virus, or any other defect which > might affect any computer or IT system into which they are received and > opened, it is the responsibility of the recipient to ensure that they are > virus free and no responsibility is accepted by Pinesoft for any loss or > damage arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: 2914825. > Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
