Who's minister of propaganda this week?

Alex Martelli aleaxit at yahoo.com
Mon Mar 19 01:53:13 EST 2001


"Marcin 'Qrczak' Kowalczyk" <qrczak at knm.org.pl> wrote in message
news:slrn9bagbm.toq.qrczak at qrnik.zagroda...
    [snip]
> Sun, 18 Mar 2001 21:55:59 +0100, Alex Martelli <aleaxit at yahoo.com> pisze:
>
> > For example, say that you want to organize certain objects in a
> > container/contained hierarchy, with no nesting limits.
> >
> > All existing objects will be leaves in the resulting tree.  Why does
> > this imply that such existing objects need to inherit from a certain
> > interface asserting "I may or may not be a container" (perhaps with
> > a default implementation stating "I am _not_ a container after all")?
>
> It doesn't imply that.

But if the container has a list of typed references, they have to
be typed to SOMETHING (which can be either a leaf of any
kind or another nested container).  The classic Design Pattern
uses just such a 'certain interface' as I just described.


> > In a dynamically typed language, you will define an interface
> > (and perhaps a default implementation thereof) *only for container
> > objects*, i.e., the "new" organizing superstructure.  Each container
> > will hold a set (e.g. a list, or dict) of (suitably tagged)
> > references to other objects; for recursive walks on the tree, one
> > will dynamically test whether a given object is-a container (else,
> > it's a leaf).
>
> In a statically typed language I would just recognize leafs on the
> container side, without relying on any properties of objects in
> leafs themselves.

So what (single) type do you make your container's references?

> You solved a problem which did not exist.

_I_?!  Have you reread "Design Patterns" lately...?


Alex






More information about the Python-list mailing list