OOP_(re)

Wed, 28 May 1997 19:38:55 -0400 (EDT)

On Wed, 28 May 1997, Peter Gerwinski wrote:

> Then it would have to be in the GPI file.  Much effort.  I think the few
> bytes we can save like that (Just those for the strings plus one pointer
> in each VMT) are not worth it, but perhaps somebody else wants to try
> himself on this problem? ;-)

This is totally optional to me, and thinking more about it, I was
wondering of what use having the symbol name of an object at runtime...

> I don't like that solution either.  It makes units compiled with different
> options *really* incompatible with each other.  (Programs using `ClassName'
> will rely on the function returning the correct result.)

Ok, then make it a program level switch, that doesn't have any effect in
units... But then, do we need it?

> > 	{ call the LoadPtr constructor, how do I do this correctly? }
> > 	{ With @Self as the 'normal' parameter of course... }
> 
>     (* I suggest to define a pointer to a procedure like the constructor *)
>     (* with an *explicit* `Self' parameter, to cast `LoadPtr' to it and  *)
>     (* then call it.                                                     *)

Its the explicit part I'm trying to avoid... I guess this part will be
compiler dependent, but should be among very few (with the TObject.Init
constructor).

> > Hmm... One thing I think isn't very clean is the way TypeOf() works "in
> > reverse"... It is *very* peculiar IMHO to set a value to a function! Maybe
> > more something like SetTypeOf(P, VMTLink)? ;-)
> 
> That's why I did "hide" it behind (*$X+*).  But maybe I should change this
> application of `TypeOf' to make `TypeOf' an implicit *field* of an object
> - which it is - instead of a function:
> 
>     PtrToMyObj^.TypeOf:= TypeOf ( SomeObjectType );

Maybe this would be better... But I don't like this very much either...
I'm against "automatic" properties or methods that you don't define. Maybe
(in fact, probably) there is a BP program that has a TypeOf property or
method, and those will have to be changed to compile. In general, I'm
against "magic" things, like the New() function, or the Write()/WriteLn()
functions (in BP at least, they cannot be implemented using the
language!).

> > Attached to this message is
> > the OBJECTS.PAS that goes with FPK-Pascal... Take a look at TObject and
> > TStream.Get implementations...
> 
> They do assembler.  Not very portable.

They have exactly two assembler part. FPK seemingly cannot call directly a
function or procedure. The LoadMethod function is there to call the Load
constructor (thru a pointer), passing the VMT link, nil as Self and a
single pointer parameter (the pointer to the TStream that is loading the
object). While this isn't very compiler independent, we can do this
explicitly with GPC (as you suggested). The other is to call a procedure
pointer again in the TCollection.ForEach and TCollection.FirstThat, which
can also be done without assembler with GPC.

> *NOTHING*.  ;-)  In principle, it would be possible to call just
> "MyObjPtr := New ( MyObjType );" without any constructor call.  `New'
> would still initialize the implicit VMT field, and one could call a
> "constructor" procedure afterwards manually.  I just implemented it
> like I did (a) for compatibility's sake and (b) because I was not so
> sure that this would really work and planned to change it to make
> constructors initilalize the object instead of `New'.  But in fact
> this seems to work and to be more effective than BP's method.

Hmm... I wonder if it is better... Oh well, it works! :-)

Pierre Phaneuf

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.


Pierre Phaneuf (pp@dilu.ml.org)