Python component model

[Edward Diener No Spam]

skip at pobox.com wrote:
>     Edward> The definition of a component model I use below is a class which
>     Edward> allows properties, methods, and events in a structured way which
>     Edward> can be recognized, usually through some form of introspection
>     Edward> outside of that class. This structured way allows visual tools
>     Edward> to host components, and allows programmers to build applications
>     Edward> and libraries visually in a RAD environment.
> 
>     ...
>     Edward> I believe that Python should have a common components model for
>     Edward> all RAD development environments, as that would allow the Python
>     Edward> programmer to create a set of classes representing components
>     Edward> which would work in any environment.
> 
> Having never used java or .NET I'm not sure what you're looking for.  Does
> Python's current introspection not work?  Is it someone too unstructured
> (whatever "structured" means)?  Can you give a simple example?

In the typical RAD development environment, a particular component model 
allows one to drop components, which are classes corresponding to a 
particular inner representation which tells the development environment 
what are the "properties" and "events" of that component, and 
subsequently set "properties" for that component and add handlers for 
its "events" visually.

Subsequently When the components are instantiated at run-time, the 
particular "properties" are automagically set and the particular 
"events" are automagically tied to event handlers in other classes ( 
usually a window, or form, although it can be in any other class which 
can handle events ). How this "automagically" is done depends on the 
visual development environment.

I find it very neat that I, the end-user of the component, does not have 
to write the boiler-plate code to set "properties" and hook up "events" 
and can do this visually. I realize that others may find this 
unimportant. But in a visual environment where not only non-viusual 
components are involved, but also visual GUI components are, this also 
allows the visual look of a particular window ( form or screen if you 
like ) to be composed automatically. At the same time hooking non-visual 
components automagically at design time so that they are connected at 
run-time to event handlers is also very nice.

In order to make such a system work, the visual RAD environment needs to 
know what in a class makes it a component, and what in that components 
specifies the "properties" and "events" for which it will automagically 
setup the correct "code" which works at run-time. Without a component 
model to tell it these things, it can not work to produce the 
boiler-plate code necessary to set "properties" and hook event handlers 
to an event.

In JavaBeans, for Java, and the System.ComponentModel namespace, as well 
as properties, delegates, and events in .Net, there exists a common 
component model which defines, in these environments, what a components 
is so that the visual RAD development can do its magic.

I realize that many Python programmers don't see the necessity for 
having a RAD visual devlopment environment doing for them what they can 
do by hand in their Python code, particularly in the constructor to 
classes. But there are people who have used such a RAD model, 
particularly when setting up a GUI application or Web application, who 
appreciate the ease of use of such a RAD visual environment, especially 
in the area of dropping visual controls on a window and having that 
window appear at run-time with the particular look which they have 
visually setup at design time. But even beyond the more common visual 
setup of a window or web page, a visual RAD environment allows the 
end-user programmer to visually create boiler-plate code for setting the 
"properties" and "events" of non-visual classes, which make up the 
greater part of the internal logic of any given program.

More importantly a common component model, which works in any language's 
visual RAD environment, enables the development and re-use of components 
which are as easily used as dropping that component from a component 
palette onto a visual container, usually a representation of a run-time 
window, and setting it's "properties" and/or "events". The visual 
manipulation of components does not preclude making manipulations at 
run-time through code also if necessary, and all visual environements 
allow the setting of "properties" and "events" at run-time also in the 
usual way.

If one has used Borland's Delphi or C++ Builder IDEs, or Sun's NetBeans 
or IBM's Eclipse for Java, or Microsoft's Visual Studio for .Net, one 
knows what I mean as far as a visual RAD environment. All of these are 
made possible by a common component model which different development 
environments can use.

There's nothing wrong with Python's introspection. In fact Python's 
facilities in this area and its support for metadata are stronger than 
any of these other languages ! However there is no common component 
model which specifies that X is a "property" or Y is an "event" of a 
Python class which can be visually manipulated at design-time and 
automagically set at run-time, so that any given Python RAD visual 
environment will treat a Python class, specified as a component, in 
exactly the same way. Also in these other languages, a component is 
different from a class in that a component is recognized in a particular 
way, often so that the component can interact if necessary with its 
container and/or visual site.

OK, I have proselytized enough <g>. Python is a great language and I 
truly love it and its flexibility and ease of programming use. If there 
is no impetus to create a component model for re-usable components for 
visual RAD environments in Python, that's fine with me. But I thought 
someone from the Python development community, given the use of visual 
RAD environments for other languages as mentioned above, to create GUI 
and large-scale applications, would have considered it.