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

On Thu, Jul 14, 2005 at 08:41:53PM +0100, Hamish Lawson wrote:
> If a PyDO table class T specifies the table name then the mechanism
> for guessing it isn't invoked. But a class T1 derived from T will
> attempt to guess the table name (nad perhaps get it wrong), unless T1
> itself defines the table name or T sets guess_tablename to False.
> Rather than guessing the table name, would it not be better for T1 to
> use the table name defined by T?

That sounds inconvenient, but 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',)

  assert A.table=='a'
  assert b.table=='b'
  assert c.table=='c'

That was the case for which these inheritance semantics were
optimized.  Admittedly, there are other cases. Whether one case should
be given preference to another, on the basis of likely use, I don't
know.

One (perhaps minor) reason to prefer the existing semantics is that it
prefers (*except* in the case of projections, obviously) the
information stated in the class definition to inherited information;
I'd say it is slightly more readable, once you get the idea that class
names are by default taken to be table names, and that if the class
name isn't the same you put in a table declaration -- this is another
way to view the existing inheritance semantics, as preserving that
rule regardless of the inheritance situation.

Anyway, if you want two classes for the same table, a projection may
be adequate:

 D=A.project('id', 'deity', 'dude')

If not, you'll have a class with a name that isn't the same as the
table, so the best thing to do anyway is to reassert the name, if only
for legibility. 

So, in sum, I don't think that changing the behavior here would make
it clearer overall; in fact, I'm inclined to the opposite view.  I
feel a terrible stick in the mud, if that is any consolation!

Cheers,

js

-- 
Jacob Smullyan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC2HwmuqamFyFXXLIRAmyWAJ96PGuwpkOCsbEWKI8bnkZ3l12QQACghUYV
amb/WZWt/XlOoiJEoMcavrQ=
=OOdU
-----END PGP SIGNATURE-----