Python component model

[val bykoski]

Peter Wang wrote:
> 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
> 
Excellent post, Peter.  Thanks for great clarification. Looking from a
physicist' perspective, im always trying to compare/evaluate languages
from "the physical reality/dynamics" angle.  So, the run-time
space/dynamics is the only one that matches the natural "always-runtime"
objects - atoms, molecules, EM fields, biological cells(?).  It is the
*reactive* world with event/forces-driven dynamics.  Seemingly, there is
nothing beyond that, including biology.

The essential feature of that runtime world is the persistence or (in
physical terms) the built-in memory/storage mechanism (soft degrees of
freedom), so that an event (and response to it) changes the object.  The
persistence is obvious in biology, but also is very important in
(bio)molecular dynamics.   From that physics/QM angle, a generic
("always-live") object  which learns the environment (by building *and
updating* its responses) seems to be a quite adequate representation for
a real physical object.  But this seems to be already available in
Python, right?

The Enthought' Traits that describes (physical) properties and their
dynamics seems to be a critically important component of that vision,
and i admire the Enthought' people vision and practical efforts.  Keep
on and good luck!
run-time-ly, y'rs

Val
Air Force Research Lab
Hanscom AFB, MA
val.bykovsky at hanscom.af.mil