OOP_(re)

Fri, 30 May 1997 15:13:59 -0400 (EDT)

On Fri, 30 May 1997, Peter Gerwinski wrote:

> > Yes, but what do you need to do with IDs?
> 
> The unique ID can be stored in a stream; the address cannot.

Did you look in BPCOMPAT OBJECTS.PAS how the SelfID is generated? This
will not survive being put into a stream from a run to another and is
basically unreliable. You could just as well store the address and hope
the object gets the same address the next time it is loaded.

> Use:  Think of a tree of objects holding numerical data.  A method of
> an object somewhere in that tree wants to calculate something.  For this
> purpose it needs some data stored elsewhere in the tree.  Then the
> unique ID can be used to locate that other data object.

Yes? Simply use the address instead of the ID, will do exactly the same
thing.

> However numbers are not flexible enough to achieve this functionality
> with reasonable effort.  I will use strings for this purpose - as explicit
> data fields of some object relatively close to the root of my object
> hierarchy.

Hmm... Could you give me an example of an integer (or better yet, the
instance pinter) not being flexible enough? And how do you plan to do your
string system??

> > Where do you get the SelfIDs from? Perhaps a list of IDs stored in a parent
> > object? You could put the addresses there instead, couldn't you?
> 
> The IDs must be arranged in a way that you can read off them what kind of
> object we have.

Using the BPCOMPAT ObjectList object (this isn't in BP), you could simply
walk the object list and use the pointers in TListUnit.

> Although I think there is wide need for this information, I think it's
> the choice of the programmer to include it, so it should not be included
> automatically ... except perhaps when emulating Delphi, but then it's
> optional, too.

A wide need for this information??? Just give me a single example where
knowing the class name at runtime would be useful, not taking into account
debugging purposes, where you could/should use a debugger or normal
constants.

> > I assume "pure virtual" is the same as "abstract" methods!?
> > I.e., any class that has at least one abstract method can't be instantiated.
> 
> Is it correct like that?
> 
> 
>     Type
>       MyObj = object
>         Procedure Foo; abstract;
>       end (* MyObj *);
> 
>       MySecondObj = object ( MyObj )
>         Procedure Foo; virtual;
>       end (* MySecondObj *);
> 
> 
> `MySecondObj.Foo' must be implemented, and `MyObj.Foo' mustn't?
> And calls to `Foo' in instances of `MyObj' would yield a run-time error?

MyObj.Foo shouldn't be implemented, exactly. But having a call to
MyObj.Foo generate a run-time error would be exactly like how it is done
now in BP. It is simple: a class containing one or more "abstract" methods
shouldn't be allowed to be instantiated. Presently you *can* instantiate a
TStream object, but this will yield a run-time error as soon as one of the
abstract method are called (because their implementation consist of a call
to Abstract, which has a call RunError()). If TStream would use an
"abstract" keyword to indicate its abstract methods, it wouldn't even be
allowed to be instantiated. The compiler would yield a compile-time error
where possible (so that code instantiating TStream wouldn't even compile)
and generate a run-time error where the illegal instantiation couldn't be
detected at compile-time. (with our AssignType() function for example)

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)