OOP_(re)

Sun, 8 Jun 1997 20:06:17 +0200 (MET DST)

According to Frank Heckenbach:
> 
> As Pierre said: string comparison are less efficient than integer compares,
> and generally I think *internal* things (i.e. things that must only be read
> by computers, not by humans) should use integers rather than strings when
> there's no real need for strings. Resource files, AFAIK, are binary files,
> anyway, so what good would it be to have some strings scattered in them?

BO4 has the following `ExecDialog' procedure:

    Function ExecDialog ( Index: String; Data: Pointer ): Word;

It gets the dialog from the resource file at index `Index' and lets it
work on the data pointed to by `Data'.  The return value is the command
the user entered to leave the dialog.  It's quite similar to TV's
ExecDialog, except that you don't pass a pointer to the dialog but an
index to the resource file - the object's ID.

A typical call:

   Var
     MyImportantData: record
       foo, bar: Real;
     end (* MyImportantData *);

   if ExitDialog ( 'EditImportantData', @MyImportantData ) <> cmCancel then
     UpdateEverything;

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.

> [...]
>
> So both IDs could coexist peacefully... :-)
> 
> Syntax proposal:
> 
> Object(...)[StringID,NumID]

Why not?  Looks reasonable ...

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

> [QueryInterface, etc. ...]

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.

> 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.

> > [Example: GCC compiler back-end ...]
>
> Sorry, I don't really feel like wading through 100kB of C code now, but I
> guess they put in the "unused" fields because they're emulating objects --
> for lack of an inheritance mechanism that allows to add fields when they're
> really needed. So I don't see how this would apply to gpc OOP.

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.

> [Implicit type cast with `is' operator ...]
> 
> I don't know how difficult this is to implement, but it would be a nice
> feature. E.g., in a program I have some situations like:

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.)

What does The Standard say about this?

    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 [970510] - http://home.pages.de/~gnu-pascal/ [970125]

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