Python component model

[Edward Diener No Spam]

Kay Schluehr wrote:
> val bykoski wrote:
>> 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.
> 
> A more conventional notion is that of static/dynamic properties of a
> language. Component models that guarantee certain properties at compile
> time are easily checked for consistency but to many programmers ( I
> guess most of the programmers who attend to this list ) they are
> inflexible: you might change or adapt your components according to
> events, switch between entities, enable dynamic configuration etc. This
> can be achieved in C++, Java etc. as well but not without pain.

Having "static" properties and events is necessary for visual RAD 
programming environments, where connections are being setup between 
events and event handlers, and properties are being initialized, at 
design time. This does not preclude the normal "dynamic" attributes of 
Python. However if Python programmers reject such visual RAD programming 
environments as having any value, then they probably won't be interested 
in a common component model for them.