OOP_(re)

Fri, 30 May 1997 15:41:45 +0200 (MET DST)

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]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)