OOP (Was: bpcompat-1.0.zip)_(re)

Sun, 25 May 1997 22:06:23 +0200 (MET DST)


According to Frank Heckenbach:
> 
> Though the VMT format might not be likely to change, perhaps it would be
> better to have a built-in function of the compiler to return the object
> size of a given VMT link (should be easy to implement).

It's easy to implement as a function:  Let `pObject' be a pointer to
the parent object `tObject'of all `Stream'able objects, then

    (*$X+*)  (* For hackers, only *)

    Function ObjectSizeInBytes ( VmtLink: Pointer ): Word;

    Var
      O: tObject;

    begin
      TypeOf ( O ):= VmtLink;  (* Initialize it manually *)
      ObjectSizeInBytes:= SizeOf ( O );
    end.

According to Pierre Phaneuf:
>
> This wouldn't work (in BP at least), since this will call TObject's Load
> constructor and it will reset the type of the object to TObject, whatever
> has been set with TypeOf().

In GNU Pascal, initialization takes place outside the constructor as some
additional inline code.  (I am not 100% sure that this will not change.)

But you are right - this does not work in the current GPC either.
But I can modify GPC such that constructors only initialize an object
if it has not been initialized previously.  Then it will work, since
assignment to `TypeOf ( something )' *is* (manual) initialization.

According to Frank Heckenbach:
>
> Couldn't "Load" be a virtual method instead of a constructor (perhaps a
> Boolean function that returns if it didn't fail)?

Yes.  IMHO, it could be in BP as well.

> But if it's possible, you also wouldn't have to register the Load constructor
> (neither Store, of course), so the registration could also be simplified to
> something like
>  RegisterType(ObjType, VMTLink:Word);
> and the programs that use this function don't have to declare a "StreamRec"
> manually, which would be another simplification.

Exactly.  For compatibility's sake, somebody should implement the
"StreamRec" stuff, too, but it can be done in an easier way.

> And it would be even better if the compiler could do this automatically,
> i.e. each object type could (optionally) declare an "ObjType" value, and
> the compiler would provide functions to get the ObjType from a VMT link
> and vice versa.

Sounds nice, but how to find a unique number for each object?  Derive it
from the name?  Then what about storing the name of the object itself
in the Stream?

> Thinking about how to implement this, I realize this is basically the same
> as object constants -- something that's missing in BP and I could've used
> sometimes. This could be a useful extension to BP's objects. (The constants
> and their values would be inherited if not redeclared, just like virtual
> methods.)

And they would be stored in the VMT.  Sounds reasonable.  And the compiler
could (optionally?) provide an automatic "name" object constant and/or a
unique number ...

> [...]
> 
> Just some ideas...

Sounds good, but I think the "stabilization" of gpc-2.1 has higher
priority.  But this might be of interest for gpc-2.2 ...

Greetings,

    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)

HTML conversion by Lluís de Yzaguirre i Maura
Institut de Lingüística Aplicada - Universitat "Pompeu Fabra"
e-mail: de_yza@upf.es