OOP_(re)

Mon, 9 Jun 1997 00:31:54 +0200

Peter Gerwinski wrote:

> Now suppose, the index 'EditImportantData' were an Integer, say 42.  Of
> course, there would be a constant declaration `Const EditImportantData = 42'
> in some Unit, so the call would be the same but two apostrophies.  Okay.
> But now we introduce more dialogs which are thematically related to
> the 'EditImportantData' dialog, e.g. 'EditEvenMoreImportantData'.  A natural
> choice for a numeric constant for it would be 43, but that's busy already.
> So we can either change *all* numerical constants and recompile the whole
> application or declare `Const EditEvenMoreImportantData = 3742' - whatever
> is free - which invites for errors when forgetting which numbers represent
> which dialogs.

As I said, IDs must be chosen with a little more sophisticated mechanism.

Since nobody told us anything about these Delphi/Windoze things, I'm just
suggesting something. Let's say the ID is a 64 bit integer (if Delphi has
128 bit, that might be more compatible, but I don't know...). So let's say 32
of these 64 bits are a unique programmer ID. The other 32 bits can be used by
the programmer as (s)he chooses. So you could use 16 bits as a unique unit ID
(I guess you won't write more than 65536 units in your life), and 16 bits as
a unique ID per unit (max. 65536 classes per unit). No renumbering necessary
ever, even if you included someone else's sources! :-)

So you could declare:

const JHackerID=$E94F561A00000000; {Your ID, declared once, globally}

const JEditorID=JHackerID+$12000000; {For each project}

const EditUnitID=JEditorID+$240000; {For each unit}

const EditCommandsID=ThisUnitID+$1000; {For each "kind" of IDs}

const EditImportantData=EditCommandsID+42;

You may or may not need either or all of project or unit level or "kinds" of
IDs, that's any programmer's own choice.

> > Object(...)[StringID,NumID]
>
> Why not?  Looks reasonable ...

Fine! :-) Then we've only got to decide about the size of the NumID. I think
64 or 128 bits are reasonable, but which?

> (* However I still think it is the job of the library, not the compiler,
> to provide such IDs. *)

But typing "const ClassName:^String value @'EditImportantData';" is not
very convenient, is it? (Apart from the fact that the syntax "@'...'"
doesn't work, does it? So it would be even more complicated to declare,
or one would have to use a CString.) Besides, a check for duplicate NumIDs
could only be done at runtime. :-(

So the compiler could help a little. Since it's only optional (it will not
be linked in if not used), I see no disadvantage.

> Delphi users:  Please help us poor guys to understand how Delphi works,
> then there is a chance that you can have all these nice features in GPC,
> too, one day.

Yes, please!

> > In which class, and pointer to which class? Sure, a pointer to TObject could
> > do anything, but would require type casts (which I consider bad style), or
> > absolute declarations (even worse).
>
> Think of a large, well-established library.  Now somebody wants to modify for
> some unexpected situation.  Then the programmer (i.e. the user of the library)
> can either directly add fields whereever appropriate - then communication with
> other applications which use the same library might become complicated - or
> use these "hook" fields.

I don't understand. Adding fields without code that accesses the new fields
doesn't do anything. So if you add the new fields, you'll also have to
provide new methods, won't you? So you'll have to derive new classes with the
new methods, and those classes get the new fields. That's what one would do
normally.

> GCC has such extension fields at a number of places:  For example, each
> structure which represents a "type definition" has one "pointer" field
> pointing to a "struct lang_decl" which must be defined by the language
> front-end using the GCC back-end. We use this, for example, to store an
> additional integer in the type definition node which tells whether something
> is a String, a Schema, an Object, a variant Record, or just an ordinary type
> - plus some pointers holding Object inheritance information and Schema
> discriminants.
>
> Of course, this could have been achieved by deriving a successor object,
> because this happens in the "highest level" of an "object hierarchy": there
> are no "successor objects" of the "type definition object".  But if there
> were, inheritance would not work any more - this "hook" field still would.

What kind of successors? AFAICS, these different types (Strings, Schemata,
Object, variant Record, ...) *are* the natural descendants of the abstract
type "TType".

Can you give me an example of another "orthogonal" inheritance? If it is
specific only to one language, this language would declare an abstract
successor of "TType" with the "hook", which would probably be more specific
than just "PObject" then. Other languages wouldn't have the hook.

That's one of the main ideas behind OOP: not having to provide "holes" for
any unknown future extensions, but being able to add what's needed when it's
needed.

> I agree that this would be nice, and I think that this would not be as hard
> to implement as one would expect on the first guess.  (Frank, it's a similar
> thing as your suggested `iftype' for accessing variable argument lists.)

I know, but AFAIR there wasn't much response to this suggestion. But with
objects it seems easier to do than with normal types.

> What does The Standard say about this?

Actually, which standard? Do you mean Object Pascal? How much does gpc
comply to this standard at all? (Up to now, we've only oriented on BP
and some ideas of our own, haven't we?)
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)