Delphi classes_(re)

Sat, 5 Jul 1997 16:16:55 +0200 (MET DST)

According to Ken Linder:
> ...
> published
>    Caption : string;
>    Status  : (Maximized, Minimized, DontKnow);
>    SomeNum : integer;
> ...
> Lets say the above is part of an object that can be 'dragged' onto the
> desired window. (Yes, I know I am talking Windows here)  Selecting the
> object after it is dragged onto the window will make the 'object inspector'
> display all 'published' properties of that object.  The object inspector
> will allow the programmer to enter some string for Caption, select one of
> the enumerated values for Status, and an integer for SomeNum.  At run-time
> the object inspector don't exist.  It is strictly part of the Delphi (and
> C++ builder) development tool.

I understand this as follows (please correct me if I am wrong):

The object inspector, a development tool, lets you specify values for
`published' variables interactively.  After that, a copy of the object
is stored in a resource file read by the application.  Like this, the
program can (and will) use an instance of the object with the fields
having these values.

> You can also attach specialized editors for
> complex properties.

So you can extend this functionality of the object inspector.  When
implementing it for GPC, we should do this from the very beginning:
The library somehow exports methods how to edit these fields.

All this can easily be implemented in a library without touching the
compiler.  In Delphi, they obviously implemented it in an external
program which reads some data about the application (kind of debugging
information) which requires close interaction with the compiler.

> The inspector also allows the programmer to attach
> functions and procedures to events but that is VERY windows based due to the
> message passing nature of the Windows OS.
                                ^^^^^^^^^^
(* "Windows program" or "Windows server program".  It's no OS, but a GUI.
Let's call it "platform" which covers both. ;*)

Messages are not Windows-specific.  Turbo Vision has them, too, so does
the OS/2 presentation manager, and, AFAIK, X always did, too.

What Borland did with Delphi was to design the compiler to work
together with exactly one library (VCL), exactly one set of development
tools (object inspector etc.) on exactly one platform (Windows).  I don't
like this approach because it contradicts the general applicability of a
compiler.

For GPC, we should better implement a library (our VCL equivalent; GCL?)
which comes with a set of development tools which works with this library,
but can be adapted to work with other libraries as far as possible (e.g.,
it reads some information about the library from a configuration file
included in the package).  The compiler can produce information of general
interest (perhaps the debugging information is already sufficient) read by
the development tools, but any library-specific information must be
produced by the libary, not by the compiler.

    Peter

 Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
 maintainer GNU Pascal [970624] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)