On Wed, 28 May 1997, The African Chief wrote:
Well, this is *exactly* what object-orientation is there for, so you add the fields when you need them. TObject itself is a "do-nothing" object. As such, it is *not* windowed and should *not* have any Handle field as it won't ever have ANYTHING in it! A TWindow descendent shall add this field.
Yes (but Handle is present in Delphi as well). However, the main reason for keeping it is because the OBJECTS unit exports a function which returns a pObject, which can be used to locate an object instance by its Handle (i.e., given any Handle, you would thereby be able to locate its owner). This can also be done via the object's SelfID (see below) in cases where the SelfID and Handle are different (which would invariably be the case).
Maybe the InstanceFromSelfID is valid (though I'd simply use the instance pointer as a handle), but (in a Turbo Vision context) only TView should have a Handle, because it is the first class that can possibly have a window handle. The InstanceFromHandle would hence return a PView or a PWindow, which is much more useful, since TView/TWindow has methods for window manipulation that TObject doesn't even have.
This is not an academic issue, because I have seen the utility of this facility in other contexts (viz - my portable "CHIEFAPP" class library, for BP 7.x, Delphi1 and Delphi2, from which project this OBJECTS unit was borrowed and cannibalised). Thus, the fields need to be in the ultimate "mother of all objects".
I think you could have done the very same (maybe even cleaner regarding the design) without adding any special fields to TObject.
It has a present use - to be able to locate every object instance by its own unique ID. See above.
The instance pointer is an unique ID, why have another redundant one?
Pierre Phaneuf
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra.