OOP_(re)

Fri, 6 Jun 1997 03:18:48 +0200 (MET DST)

According to Frank Heckenbach:
> 
> > At least a `BPcompat Objects' Unit *must* have this FillChar. :-|
> 
> Hmmm... there could be problems if an object in a ported BP program has a
> string field (at least until short strings are implemented and "string[]"
> automatically generates short strings).

I hope that I will be able to implement them not too far in the future.

> BTW: Do TV programs actually rely on the zeroing out, or is this just a
> paranoia initialization?

They do.

> [...] Since gpc
> favours speed instead of size, I think it's good to do the initialization
> outside.

Agreed.

> But then the question is whether to initialize the VMT before the call.
> With the method below, it's simple: initialize it if (and only if) it
> hasn't been initialized before.

Exactly.  This implies that pre-initialization is necessary.

> I think this is a good idea. Perhaps also resetting the VMT after a
> destructor call (which is superfluous in a Dispose statement, of course).

Yes.

> [String constants as Object IDs ...]
>
> I don't think so. If Delphi does it in a bad way, we don't have to duplicate
> that. But it would be good if a Delphi user could actually check what Delphi
> does.

I don't think it's so bad:  Strings are more flexible than Integers.  I really
like to index a `RessourceFile' (in TV) with Strings ...

> If the "other prorgam" is part of the standard library, it would be ok (just
> adapting our library to accept integers). Otherwise perhaps declare a
> function to convert a numeric ID to a string. This function would have to be
> inserted into the Delphi source then, but with a dummy function declared in
> Delphi, the code could still be used in Delphi.

Anyway, I have more and more the impression that "Delphi compatibility"
users desire does not mean that the GNU Pascal compiler must be able to
compile Delphi's VCL, but that GNU Pascal has its own "VCL" with a 100%
compatible API.

> BTW: What about the QueryInterface things? They might make "100% source
> compatibility" with Delphi impossible, anyway, as soon as interfaces are
> used.

??? Sorry, I don't understand.

> Doesn't the same apply to your method? You pointers are non-standard, too.
> E.g., when you want to convert them to an untyped pointer, you have to
> subtract the offset from them.

Yes.  :-(  A lot of work, which invites for many hard-to-decect errors.

> I think I've found a third way, one that doesn't influence the pointer format
> and doesn't blow up the objects. It does, however, waste some space in the
> VMTs. I'm sending it to you by private mail (mainly because it's easier for
> me to describe it in German) -- sorry to other readers of the list who are
> interested in this discussion, but we'll post the results back to the list
> -- whatever it will be finally...

One pre-result:  I like that third method, but it causes some techical
problems as well.  This task *is* a nontrivial one!

> AFAIS, this is the "aliasing bug" and can be solved with pointer-pointers.
> (See my reply to the chief, later.)

Where would that pointer-pointer reside, and who would initialize it?
When the object shows up, it must ensure that some other objects which might
not yet be in memory will be able to find the pointer to it, so they can set
up their pointer-pointers.  This task works without IDs if (and only if?)
both objects are loaded at the same time.

> No, you don't disagree! :-) I said "if this doesn't work well..." --
> obviously it did after your changes! :-)

It did, and it still does. :)  However, BO4 is still 16-bit technology,
supports every graphics card from CGA, Hercules, etc. to VGA (and even the
EGC card, which I saw only at two places ...), assumes DOS 2.11 and at least
one floopy disk drive (hard disk recommended, but not required), etc.  It's
time for something more powerful and not restricted by Borland's copyright!

> But how many fields and which type??? I don't think that's a good idea.

One additional field of type "pointer to base object" will allow to
store as much additional information as desired with the object.

Some additional Boolean fields, stored in a packed array, cannot hurt.

See `tree.*' in the GCC source code for an example of what I mean with
"extensibility". The "tree nodes" used in the GCC and GPC front-end are
in fact Objects (written in C, not in C++!), and they contain such
extension fields at some central nodes in the object tree.

> Actually, this is quite a general principle to get something like "separate
> inheritance" (of different parts of an object), by splitting up the object
> into several part-objects. There is an overhead (one additional pointer and
> its dereferencing), OTOH one can often eliminate case discriminations by
> clever use of virtual methods in the new part-objects.

:-)  Just what I proposed above:  One additional pointer.
It seems that we in fact agree, but we chose different words for it.

Greetings,

    Peter

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