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 <[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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
