Python component model

[Peter Wang]

Edward,

This isn't in response to any specific one of the 100+ posts on this
thread, but I justed wanted to encourage you to continue your
investigation into Python component models and maybe looking for some
common ground between them.  Frequently the individual developers are
too heads-down on working on their own things to do a broad survey, so
I think this would be very useful indeed.

I wouldn't have felt it necessary to post this except for the large
number of posts along the lines of "foo.dict is introspective enough
for me!".  I think you might have an easier time evangelizing the
principle of component-oriented programming (or "event-based", or
"reactive", or whatever) if you separated it from the notions of RAD UI
development.  There is a very large difference between writing
components and writing objects, and it seems that most people arguing
"python doesn't need components" don't see this distinction.

For me, it's the difference between writing "live" objects and "dead"
objects.  Live objects not only encapsulate implementations of an
interface with some state, but they also encapsulate handling of
events, i.e. responses to changes in their environment.  Dead objects
have methods but there has to be a function somewhere that knows which
dead object to call with what parameters at exactly the right time.
(The only mechanism for managing this complexity is to create ever more
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.


-peter