105 lines
5.0 KiB
Plaintext
105 lines
5.0 KiB
Plaintext
From: earlybird at mop.no (Alexander Staubo)
|
|
Date: Tue, 25 May 1999 06:24:46 +0200
|
|
Subject: Defining VCL-like framework for Python
|
|
References: <MPG.11ac42bf5a6c7d66989685@148.122.208.74> <37437C55.3E49@cosc.canterbury.ac.nz> <MPG.11afb53fe1d04081989735@news.online.no> <7i4bnp$kh0$1@cronkite.cc.uga.edu> <MPG.11b0d2911c091112989736@news.online.no> <7i9nq5$a9m$2@cronkite.cc.uga.edu>
|
|
Message-ID: <MPG.11b44476bf13c5b598973e@news.online.no>
|
|
Content-Length: 4634
|
|
X-UID: 1849
|
|
|
|
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
|
|
|
|
|
|
|
|
|