Variable inheritance

[Roman Suzi]

On Tue, 22 May 2001, Alex Martelli wrote:

>Not necessarily so, in Python.  Say the user chooses
>'feature-sets' he wants by 'copying' the feature-set
>names in a GUI from a list to another, e.g. by drag
>and drop; he may also arbitrarily reorder the list
>of feature sets he has chosen in terms of priority --
>if two chosen feature-sets both provide a way to
>handle a certain behavior, the user gets to choose
>which one takes precedence.  This might be excellent
>as a user-interface in a bridge-bidding system to
>choose sets of bidding conventions, for example.  When
>done, the user writes in a name for the new thingy in
>an appropriate text-field, and clicks the "Create"
>button.

the already mentioned by me http://www.geocities.com/tablizer/oopbad.htm
(and related pages) agrues that feature sets are better done with feature
tables, where you can check-in features (object attributes) you need in
any mix.
This way you will see exactly what fetures you've choosen
and what not.

This gives better granularity than MI could provide.
Just pick your fetures directly, why do you need
inheritance?

>OK, so now we have a tuple of 'feature-sets' (classes)
>whose features the user desires in the object he is
>creating.  What is the best way to mix them?
>
>Why, multiple inheritance, of course -- what else?
>
>class ObjectCreator:
>    class Starter:
>        def __init__(self, name):
>            self.name, self.uniq = name
>            for b in self.__class__.__bases__:
>                getattr(b,'__init__',lambda x:0)(self)
>    def __init__(self):
>        self.classRegistry = {}
>        self.nameRegistry = {}
>    def create(self, name, basestuple):
>        if not self.classRegistry.has_key(basestuple):
>            class Temp((Starter,)+basestuple): pass
>            self.classRegistry(basestuple) = Temp
>        uniq = 0
>        while self.nameRegistry.has_key((name,uniq)):
>            uniq += 1
>        name = (name,uniq)
>        result = self.classRegistry[basestuple]('%s_%s'%(name,uniq))
>        self.nameRegistry[name] = result
>        return result
>
>I don't see how aggregation and delegation would be easier
>to implement and maintain than this simple framework.

It depends. Python has great functional capabilities
to make container-writing (with proper dispatching
of messages) very easy.

I can't agree Python's MI is a way to do HAS-A
relations. It seems to me like using only

from A import *
from B import *
...
from X import *

applied at the class level.

> You
>can add new potential base-classes anytime, in fact updating
>the UI is more than a chore than updating the underlying
>engine (since the latter doesn't need to be updated:-).
>
>All the work you would have to code in delicate boilerplate
>in Python for the delegation is handled by Python itself
>as it looks for methods and other attributes of the objects
>so created.  And isn't this exactly as it should be?
>
>
>Python gives us a flexible, solid, powerful code reuse
>mechanism in its inheritance structure.  I don't see why
>one shouldn't take full advantage of it just because of
>mistaken (or at least SERIOUSLY debatable:-) philosophical
>ideas on the role of taxonomy in classification!-)

BTW, is there any book or other source which explains
OOP python-wise?


Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rnd at onego.ru _/
_/ Tuesday, May 22, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Never trust a computer you can't lift. - Stan Masor" _/