Hi all,
I have been following the discussion on Objects with interest. I would just like to note a number of things;
The TObject type as I implemented it in OBJECTS.PAS has a number of fields; "Parent" and "Child" (each declared as a "pObject") "Handle" and "SelfID" (each declared as an Integer) "Name" (declared as a String[64]) "SelfPtr" (private field declared as a "pObject")
At the moment, "Parent" and "Child" do nothing, and "Handle" is for projected future use (for handles to windowed objects - Win32, etc).
"SelfID" is an integer which holds a unique numeric ID for each living TObject descendant.
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?; if so, can this solve any of the current problems with Streams and stuff?
I would have thought that some of the fields declared in TObject could be put to better use than I have done so far - and that more fields could be added to TObject, to cater for other things (i.e., if TObject will become the ultimate ancestor of all Object types).
Any views?
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
On Mon, 26 May 1997, The African Chief wrote:
The TObject type as I implemented it in OBJECTS.PAS has a number of fields; "Parent" and "Child" (each declared as a "pObject") "Handle" and "SelfID" (each declared as an Integer) "Name" (declared as a String[64]) "SelfPtr" (private field declared as a "pObject")
At the moment, "Parent" and "Child" do nothing, and "Handle" is for projected future use (for handles to windowed objects - Win32, etc).
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.
"SelfID" is an integer which holds a unique numeric ID for each living TObject descendant.
Does this have any projected use?
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?; if so, can this solve any of the current problems with Streams and stuff?
This is not really desireable. This will only impose on people our TObject structure. I have a different TObject and Turbo Vision has a different TObject and we can both live together with the same compiler (of course, don't use both Units!) without any problem. It wouldn't solve anything regarding streams anyway...
I would have thought that some of the fields declared in TObject could be put to better use than I have done so far - and that more fields could be added to TObject, to cater for other things (i.e., if TObject will become the ultimate ancestor of all Object types).
Posted on this list is the OBJECTS.PAS unit from Free Vision (the object library of FPK-Pascal). It is *not* a better object library, but it is a good compatible unit adapted to works correctly in 32-bit. *Very* conforming, they even put the friggin' Free method with a "god I hate this" comment... :-)
Pierre Phaneuf
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra.
-
Pierre Phaneuf -
The African Chief