import statement - package visibility problem

[Laszlo Zsolt Nagy]

>
> Two solutions come into my mind:
>
> 1. Do not inherit from DatabaseConnection, but pass a 
> DatabaseConnection object as a parameter to the FireBirdConnection's 
> __init__function. After this you can delegate the necessary 
> functionality to the DatabaseConnection (by using __getattr__). This 
> introduces less coupling between DatabaseConnection and 
> FireBirdConnection, event module testing is easier.

I do not like this solution. I would like to use the classic 
'generalization/specialization' idiom, where the base class defines the 
interface and some common methods; while the descendants are 
specializing the basic classes. The language should allow me this 
classic approach and indeed it does.

>
> 2. Maybe the layering of your application is wrong. If 
> DatabaseConnection provides common functionality to the different 
> Adapters, it should be on the same layer or one beneath the Adapters.

I have a bad feeling about it. For example, I have database related 
modules under Db. I would like to implement the basic abstract classes 
at the top level, then implement the specialized classes at deeper 
levels. E.g. I can access DatabaseConnection, DatabaseSchema, 
SQLProcessor and similar classes in the top level module "Db". I would 
like to implement as much functionality in this abstract level as 
possible (reusing code is important for me). Then at some point when I 
want to implement something - for example, a connection class for 
PostgreSQL databases - then I only need to implement the unimplemented 
or extra features of a PostgreSQL connection. There can be many 
different implementations, this is why I want to store the more 
implemented (less abstracted) levels deeper in the source tree. I cannot 
imagine how could it be in the opposite direction. The abstract classes 
at the top level need to import their abstract counterparts, so I cannot 
place the abstract classes in the deepest folders - I need to place them 
at top level because they use each other very frequently. Do you 
disagree? Is this a bad design from me?

-- 
_________________________________________________________________
  Laszlo Nagy		      web: http://designasign.biz
  IT Consultant		      mail: gandalf at geochemsource.com

     		Python forever!