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]