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 -- http://mail.python.org/mailman/listinfo/python-list
