On Wed, 28 May 1997 16:40:06 +0200 Frank Heckenbach heckenb@mi.uni-erlangen.de wrote: [...]
At the moment, "Parent" and "Child" do nothing, [...] "SelfID" is an integer which holds a unique numeric ID for each living TObject descendant.
AFAICS, they will hold the parent/child *objects*, not *classes*, and the ID of instances. Also useful, I think, but not to be confused with the parent/child classes, and "ObjID" (= class IDs) which should resonably be in the VMT, since they depend only on the class, not on the instance.
True.
Can we make TObject automatically become the ancestor of each Object type (i.e., any object which is just defined as "Object")?; if so, is this desirable?;
No. There are applications of OOP that are quite different from the class libraries as TVL, OWL and so on. Sometimes I use objects as "convenient records" without any need for inheritance, virtual methods or streams.
I do too - fair enough ...
AFAICS, objects that are stored in streams, must be descendants of TObject.
Correct.
But not all types of objects need to be able to be used in streams at all.
Correct again.
I think the programmer should be allowed to decide for himself if he wants his objects to be "streamable" (by making them descandants of TObject or its descendants) or not.
True.
[...]
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.
So if TObject was a part of the "core language", also TStream would have to be.
See above.
True for a Program, false for a Unit. While the GPC compiler is *much* smarter than BP and would remove unused code and variables, the GNU linker is not able to remove dead code, it only does so if a whole Unit is unused.
I suppose there's not much hope of getting a smarter linker in the near future, is there?
I very much hope so.
The African Chief wrote:
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).
I don't know all the details here, but isn't it possible to have a TWindow(TObject) with Handle being a field of TWindow, and this function returning a PWindow? This would seem natural to me.
Yes, that is possible. But I don't think it does any harm to have the Handle in TObject instead.
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".
Similar arguments might be applied to many kinds of fields, with the possible danger of blowing up the "mother of all objects" very much.
True.
Then it could - at best - be the mother of all objects in a particular class library, but it wouldn't promote the goal of making it a widely used base class.
Perhaps. But there are many times when I have wished that certain things existed in BP's TObject and TWindowsObject. Making a descendant object is fair enough, but it would have been a lot easier for me if the things were in the ancestor.
It has a present use - to be able to locate every object instance by its own unique ID. See above.
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... ;-)
That assumes that you already know the object and its address. If you already know it, there would be no point trying to locate it again. Also, there are a whole load of things that you can do with integers that you cannot do with addresses. And, suppose that, for some obscure reason, I suddenly wanted to locate all currently active object instances and/or their parents (if any), how would I do this using addresses? - but I could do this with a loop through the SelfIDs.
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