Re: Derived class guesses table name even when parent specifies it

Jacob Smullyan wrote:

> what about the case, such as you'll find
> with postgresql table inheritance, of wanting a PyDO class
> corresponding to table A, and then two classes corresponding to tables
> B and C that inherit from table A?  The existing inheritance semantics
> fits that nicely; you can omit the table declaration from all three
> classes:
> 
>   class A(PyDO):
>         fields=(Sequence('id'),)
> 
>   class B(A):
>         fields=('bitude',)
> 
>   class C(A):
>         fields=('cness',)

It looks like there are two different ends to which class inheritance
can be put. The purpose you mention (and which I hadn't thought about)
is modelling table inheritance. On the other hand I was using class
inheritance to allow me to define additional methods without modifying
the autogenerated table class. I think my proposal may moderately
convenience the latter without affecting the former.

My proposal only changes what happens when a table name is specified
in some class but not in a derived class: namely, that the derived
class should use the table name specified in its parent rather than
guess it. Since your scenario above doesn't specify ant table names,
it would be unaffected by this change. Moreover it's my guess that the
pattern I'm considering (A specifying a table name but B and C not
doing so) is unlikely to be used when modelling table inheritance;
either no class would specify a table name or all would. Instead the
pattern in question is most likely to be used when using class
inheritance for the purpose of API extension; and that, I suggest, is
when you'd want the semantics that I'm proposing.


Hamish


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click