Python component model

[Jacob Hallen]

In article <1160696330.090125.212900 at h48g2000cwc.googlegroups.com>,
Peter Wang <misterwang at gmail.com> wrote:
...
>functions at ever higher levels of abstraction, or to have a
>proliferation of nebulously-defined "manager" objects.)  IMHO once you
>cross this chasm and are able to model your problem domain with live
>objects that go off and automatically respond to the runtime
>environment and Do the Right Thing, it's very hard to go back to a dead
>object mindset.  I can understand, however, that until one makes this
>leap, it might seem like an academic and useless distinction.

I'm not disagreeing with the blessings of components reacting to events
and going off Doing the Right Thing. However, there is a huge with
components going off Doing the Wrong Thing. It becomes exceedingly
hard to debug for several reasons. The first one is that it is difficult
to trace the callbacks generated, since the point where they were
registered is no longer trackable when your problem occurs. The second
and most serious problem is that erroneous behaviour in two components
can interact in extremely mysterious ways that are really difficult to
debug.

In part these problems can be reduced by much rigorous testing of each
component than is the norm today, but for the really tough problems we
need tools that have not been invented yet, that track the history
of each callback. Since these tools have to understand the details
of the calling conventions and registration mechanism for events, they
have to be custom built for each component framework and should therefore
be part of the framework distribution.

Jacob Hallén

--