OOP_(re)

Fri, 30 May 1997 18:50:34 +0100 (BST)

On Fri, 30 May 1997 00:35:54 +0200 Frank Heckenbach  
wrote:

>The African Chief wrote:
>
>> >BTW: Would it be possible at all? Doesn't TObject refer to TStream?
>> No, it doesn't. In bpcompat, TObject has a "Load" constructor that takes
>> a TObject parameter.
>
>But doesn't it have to refer to the stream somehow? Do you type-cast the
>parameter into a stream 

Actually, the Load constructor in TObject does nothing at all.

>> >I'm probably missing something - but isn't the address of an object a
>> >"unique ID"? (One that makes it very easy to "locate" the object... ;-)
>
>As I said, I might be missing something, but I still don't know what it is....

See my earlier post of today.

>> That assumes that you already know the object and its address.
>
>If you used the address everywhere you use the ID now, you would know,
>wouldn't you?

SelfID can be accessed at random - e.g., through a loop. You can't
do that with addresses.

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

There is a local instance in the OBJECTS unit which allocates an ID
each time INIT or CREATE  is called. There is a function : "InstanceFromSelfID"
which returns a pObject for any given SelfID or NIL if there isn't any active
object with that SelfID.

So, I could really just do something randomly like this;

   p := InstanceFromSelfID ( 5 );
   If p <> NIL then  .....

Although of course, you wouldn't want to do that.

>I'm really trying to understand what you do with these IDs!

Like I said, OBJECTS.PAS is a cannibalised form of the main objects
unit in another project - a portable class library ( BP 7.x, Delphi 1 and
Delphi 2) - viz - using only pure Pascal and the Windows API - no OWL,
and no VCL. A lot of  that one was implemented from the perspective of 
the Windows API  and communications between all sorts of things. It
will take too much time to explain it here.

>I hope, it's not only the (bad, IMHO) tendency of Windoze to use "untyped"
>handles for each and everything - that might not matter much in C (where
>everything is int anway - well almost...), but I think in Pascal we should
>try to keep as much typed information (e.g. typed pointers) as possible.

Hmm ...

>> A purely personal thing, perhaps. If I did it my own way, without any
>> preconceived notions, I would have an ancestor object which would
>> contain everything that I think every object should have.
>
>Right, everything that *every* object should have, not everything that *some*
>objects should have. E.g. handles: not every object has a handle, so it should
>not be in the base class. If in a windowing system, every instance of TWindow
>and its childs will have a handle, then Handle should be a field of TWindow.

Let's put it this way. If I declare; "Var p : pObject", I would like to be well assured
that p^ will always have a Handle, a Name, and a SelfID. I can then use p in any
number of situations, without having to declare another pWindow just to get 
something that has a Handle. I can find out the TYPE of p by its Name.

>> > I really don't see what a TWindow object and a
>> >TString object has in common that should be in TObject!
>>
>> They could all have a Name, a SelfID, a Parent, and a Child.
>
>Do you mean a name/ID/parent/child of the *class*, or of the *instance*?

Of the class. 

>In the former case, I agree (except for the name, which IMHO usually isn't
>needed at runtime, see above), 

I have read all the discussion about VMTs. I still prefer this;
	If p^.Name = 'TCHIEF' then ....

>> >BP didn't set that
>> >trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. 
>> 
>> The first thing I would do to it is to change that omission ;)
>
>Why not simply derive one (or several) classes from it with whatever you
>want? That would be in the spirit of OOP (not to change existing classes,
>but just derive new ones from them).

One of the things I hate about some frameworks that will remain 
nameless is the multitude of ancestors. It makes it really tedious
when you are trying to find out what is really going on in an object
(sometimes having to plough through myriads of objects in myriads
of units). Sometimes inheritance can be taken too far.

Whew! Now to go home to my wife ;-)

Best regards, The Chief 
Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant)
Author of:  Chief's Installer Pro v3.50 for Win16 and Win32.
Homepage:  http://ourworld.compuserve.com/homepages/African_Chief/
E-mail: laa12@cc.keele.ac.uk


The African Chief (laa12@cc.keele.ac.uk)