In article <[EMAIL PROTECTED]>, Peter Wang <[EMAIL PROTECTED]> 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 --
-- http://mail.python.org/mailman/listinfo/python-list