Defining VCL-like framework for Python

[Alexander Staubo]

In article <7i9nq5$a9m$2 at cronkite.cc.uga.edu>, graham at sloth.math.uga.edu 
says...
> Alexander Staubo (nospam-alex at mop.no) wrote:
> : For example, JavaBeans gives you nonvisual JDBC beans for 
> : feeding data to a set of "database-aware" controls. Since a database is a 
> : high-level, non-visual construct, you can't put it on the screen, but you 
> : can interact with it through a standard set of properties (eg., 
> : "TableName"), methods ("Open") and events ("OnChange").
> 
> So I must be missing something. How does defining all these components
> differ from defining implementations of interfaces (the interfaces tell
> you the standard properties).

In Python, the distinction between class instances and a 
"component" fortunately is much less present than in Delphi, which uses 
ObjectPascal.

The core of Delphi's component architecture is its RTTI [Run-Time Type 
Information] support, which consists partly of an API for extracting type 
info from classes, types, etc. There is a class-level counterpart to this 
API, which lets you obtain the identity of a class, its name, etc. This 
architecture is arguably not ideally elegant, but it works surprisingly 
well. It permits you, for example, to enumerate the properties of a 
class, or get a string representing the name of an enumerated type.

How is this stuff used in practice? When you define a component, you 
typically designate a set of properties (attributes) as being 
"published". This tells Delphi a few things, such as that the properties 
should be visible for editing, and that the properties such be 
persistent. Whenever Delphi streams you component, it stores the 
properties well. (There's a storage modifier for disabling this.)

Properties need not be just simply data members, like C++: Delphi 
supports accessor methods tied to properties, so "o.Width = 1" might 
translate to a call to "o.SetWidth(1)".

Oh, and events are also properties. This part of Delphi is admittedly 
somewhat simplistic, and compared to the JavaBeans event system 
(for example) (which Borland actually designed), actually a tad 
primitive. But again, it works surprisingly well. Components typically 
export function pointer properties. At design time, Delphi shows these 
properties in a separate list and permits you to assign code snippets to 
them, implicitly associating the code snippet (function) as a pointer to 
the property.

The "magic" of Delphi is perhaps in the persistence mechanism. Whenever 
you a design a form, the form and its components are stored in a 
separate, proprietary-formatted binary file. This process is almost 
identical to Python's pickling except Delphi does it "the hard way", by 
using the RTTI APIs to discover properties, and then store them. Classes 
can overload the I/O functions for properties that require special 
handling.

I'm puzzled by what you mean by...

> defining implementations of interfaces (the interfaces tell you the 
> standard properties).

...though. Interface as in a Python class decl?

One reason I believe we need an additional layer or two of abstraction -- 
what I'm proposing as the "VCL-like framework" -- is that you would never 
ever want to stream _all_ attributes when streaming a "component" 
(whatever it is, and however it is implemented); only a well-defined 
subset.

A second reason is that I'd like to use acquisition as the inheritance 
model for properties. Not something that you'd easily graft onto 
toolkits like wxPython or tkinter, afaik.

A third reason is that in order to wrap a nice, warm development 
environment around the whole thing, a protocol needs to exist for 
importing controls and component-like thingies into the system. They need 
to follow a specific protocol designed for this purpose, and none of the 
GUI toolkits have that. 

There are other reasons, too. I'm considering delineating them formally 
in a proposal document rather than throwing around loosely connected 
thoughts here. Those that know Delphi seem to have grasped the idea 
pretty quickly, though. :-)

As to what is a framework, various people have explained this concept 
pretty well. I'm not sure that the distinction is significant; I for one 
would not like a totalitarian framework that imposes a completely new 
application model -- I believe we can avoid that, just as the VCL avoids 
it [pretty well].

-- 
Alexander Staubo             http://www.mop.no/~alex/
"Give me an underground laboratory, half a dozen atom smashers and a beautiful 
girl in a diaphanous veil waiting to be turned into a chimpanzee, and I care 
not who writes the nation's laws." --S. J. Perelman