Circular Inheritance

[John Roth]

"Ian Bicking" <ianb at colorstudy.com> wrote in message
news:mailman.1057124943.21695.python-list at python.org...
> On Tue, 2003-07-01 at 19:00, Ben Finney wrote:
> > Re-design the modules so that inheritance is a hierarchy.  A
band-aid
> > solution may be to create a new class that mediates between two
others,
> > breaking the circle.  Much better is to figure out why the classes
need
> > to know so much about each other, and redesign them with smaller,
> > simpler interfaces.
>
> It seems quite reasonable to have circular dependencies between two or
> more classes.  The most common case being that one class references
the
> other, and the other class has back references.  Very common, and it
> doesn't imply that the classes know too much about each other.

However, this wouldn't normally cause import problems. Import
problems are very specific: they are caused by the two modules
referencing classes or identifiers in the other module ***while they
are being loaded***. If all the modules contain are class and
function definitions, and all the class definitions contain is method
definitions, the only possible problems I could see would be the
inheritance part of the class statement, and defaults in the function
and method definitions. Both of these need to be defined at import
time.

Since inheritance is strictly hierarchical, it isn't too difficult to
import in the right order.

> You might encounter less problems if those classes go together in a
> single module, but module boundaries are just there to help the
> programmer organize code, they have little formal meaning.
>
> > Even if there were a way to do circular inheritance, it would be a
> > nightmare to understand, so needs to be redesigned anyway.
>
> He probably just meant circular dependency, since obviously
inheritance
> doesn't make sense.

And circular dependencies are difficult as well. The best policy,
as several posters have already said, is to redesign to eliminate it.

John Roth
>
>   Ian
>
>
>