According to Frank Heckenbach:
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...
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?
[...]
Yes, but what do you need to do with IDs?
The unique ID can be stored in a stream; the address cannot.
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.
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.
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.
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.
I think, if some program for any reason does need this information, it could declare object constants (if implemented), or methods (in the meantime) that provide this information explicitly, but unless there's a wide need for this information (which I can't see), I don't think it should be included automatically.
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.
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?
Many "un-definable" Pascal procedures could be defined with overloading and/or optional parameters. Both is possible to do in Pascal, and I hope, gpc will have them sometime.
My first attempt to implement that failed :-(, but I keep trying!
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970510] - http://home.pages.de/~gnu-pascal/ [970125]
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.