Abstract class

[Stephen Horne]

Re: Abstract class

On 14 Sep 2008 20:25:18 GMT, Steven D'Aprano
<steve@REMOVE-THIS-cybersource.com .auwrote:

>"The fact that many languages disallow instantiation of abstract types
>(and force subtypes to implement all needed functionality) further
>ensures program correctness."
>
>http://en.wikipedia.org/wiki/Abstract_base_class
>
>but I don't see how that follows (except possibly in very special cases).
>Given that the set of instances of class B is empty, how does that help
>you know that B.method is correct?

That's the point - to be certain that the set of instances of class B
really is empty.

As for B.method, it's correctness isn't purely determined by the code
of the method itself. It will usually depend on the object being in a
self-consistent state. It's often impossible for an instance of an
abstract base to have a self-consistent state. Therefore, it's better
to guarantee that no instances can be accidentally created.

OTOH, this argument is often an over-pedantic technicality. You can't
eliminate all errors from code by making the language stricter.
Instantiating an abstract class isn't a very common error in my
experience. Whether detecting it is a priority depends on what you're
doing.

[Mr.SpOOn]

Re: Abstract class

It seems I started a long discussion.

You pointed out a lot of interesting things. For example the math
operations over notes and intervals and the use of the modulo
operator. I already had in mind to implement such things.

Anyway, the real purpose of the project is to use these objects with
Pyke (Python Knowledge Engine) [1]. I'm not sure yet what I am going
to do, but and idea would be to find an appropriate scale for some
given chords (for example, from a midi input).

As suggested, I'm going to write code and see what is better.

Thanks everybody,
bye


[1] http://pyke.sourceforge.net/

[Bruno Desthuilliers]

Re: Abstract class (irrelevant blethering)

Stephen Horne a écrit :
(snip)

For example, to me the term "property" is basically a trivial design
pattern or an object-oriented principle. I don't really see the need
for the language feature. I can define getter and setter methods all
by myself, and I don't really see the benefit of disguising them as
member variables.

The canonical use case for computed attributes is that they let you turn
a plain attribute into a computed one if/when the need arises, without
breaking client code *nor* having to force all access attributes thru
getters/setters righ from the start "just in case".

[Maric Michaud]

Re: Abstract class

Le Sunday 14 September 2008 22:25:18 Steven D'Aprano, vous avez écrit :

On Sun, 14 Sep 2008 12:15:04 -0700, Gary Herron wrote:

(If you wish to consider the base class "abstract", just agree with
yourself to not instantiate it.)

>
That's certainly the most lightweight option.
>

Please forget about Abstract Base Classes. They have nothing to do with
what you want, and are a *HUGE* overkill for your application. They
are not (yet) even part of standard Python, and are used primarily for a
class implementor to guarantee to a user of a class that it provides a
specific interface.

>
You can implement a lightweight abstract base class in Python fairly
easily, by adding two lines to the __init__ method of your base class.
>
>
class Base(object):
def __init__(self):
if self.__class__ is Base:
raise NotImplementedE rror("Abstract base class")
def method(self, *args):
return len(args) # or something useful
>
>

But this doesn't match what abstract classes are (in C++ for example), because
__init__ can, and probably will, have logic reusable in concrete classes. The
only way to do this is to call in the __int__ at least one of the methods
raising NotImplementedE rror, probably creating a dummy one for this purpose,
and still it doesn't satisfy with the constraint that *all* abstract methods
must be implemented in concrete classes.

"The fact that many languages disallow instantiation of abstract types
(and force subtypes to implement all needed functionality) further
ensures program correctness."
>

http://en.wikipedia.org/wiki/Abstract_base_class

>
but I don't see how that follows (except possibly in very special cases).
Given that the set of instances of class B is empty, how does that help
you know that B.method is correct?

I agree with you on this, and the simple scheme of defining some methods
raising exceptions is obviously sufficiient where duck typing is.

ABC, as I understood it, is for resolving another problem : unrelated (by
inheritance) classes, which share the same signature, but need to be
distinguished in their behavior.

--
_____________

Maric Michaud

[Roy Smith]

Re: Abstract class

Maric Michaud <maric@aristote .infowrote:

The only way to do this is to call in the __init__ at least one of the
methods raising NotImplementedE rror, probably creating a dummy one for
this purpose, and still it doesn't satisfy with the constraint that
*all* abstract methods must be implemented in concrete classes.

I wouldn't actually *call* the method (because of possible side-effects),
but you could certainly check that they exist and are callable:

class Base:
"""An abstract base class. You must define methods f(),
g(), and h() in any subclasses of this.
"""

def __init__(self):
try:
assert callable(self.f )
assert callable(self.g )
assert callable(self.h )
except:
raise NotImplementedE rror # or something more specific

Of course, this assumes that you write:

class Derived(Base):
def __init__(self):
Base.__init__(s elf)

There's no way (that I can think of :-)) to *force* you to call
Base.__init__() from Derived.__init_ _().

This is all a bit silly, however. If you want type bondage, use a language
that gives you type bondage (C++ and Java being two obvious examples).

[Fredrik Lundh]

Re: Abstract class

Maric Michaud wrote:

But this doesn't match what abstract classes are (in C++ for example)

you're confusing concepts with specific implementations of those
concepts here.

</F>

[Maric Michaud]

Re: Abstract class

Le Monday 15 September 2008 16:42:49 Fredrik Lundh, vous avez écrit :

Maric Michaud wrote:

But this doesn't match what abstract classes are (in C++ for example)

>
you're confusing concepts with specific implementations of those
concepts here.
>

Maybe, that's why I gave this example, but aren't they (conceptually)
classes :

- which couldn't be instantiated,
- which define at least an interface and possibly some behavior,
- for which all the undefined methods need to be implemented in concrete
classes (the pure virtual methodds in C++)

?

That's the exact implementation in C++ but I'm not aware of any other language
that implement this notion. Java simplified this a lot, abstracts are
interface (type), no behavior.

--
_____________

Maric Michaud