[Pharo-project] about class abtractness
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
****************************************************************************************************************************************** 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
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 <simon@pinesoft.co.uk> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
****************************************************************************************************************************************** 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I kind of agree :) On Oct 6, 2008, at 11:13 PM, Michael Roberts wrote:
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 <simon@pinesoft.co.uk> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
****************************************************************************************************************************************** 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 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
Now what was cool with nathanael browser is that it shows you on the fly that a method was broken: invoking an ill defined selector or abstract methods And normally you should not have an abstract class instantiated so been able to check would make sense. Stef On Oct 6, 2008, at 11:13 PM, Michael Roberts wrote:
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 <simon@pinesoft.co.uk> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ 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
****************************************************************************************************************************************** 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 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
participants (4)
-
Alexandre Bergel -
Michael Roberts -
Simon Kirk -
Stéphane Ducasse