Python component model

[Steve Holden]

Edward Diener No Spam wrote:
> 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.

Such a model would definitely have value (particularly if all tool 
builders subscribed to it: that was how Beans achieved ubiquity).

But there is no such model at the moment. A project to create one might 
receive support or it might not. There's one way to find out ...

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden