Delphi classes_(re)

Sat, 5 Jul 1997 16:16:05 +0200 (MET DST)

According to Frank Heckenbach:
> According to myself (Peter Gerwinski):
> > It's "class" = "reference to object".  Fortunately, the GCC front-end
> > is able to deal with such things,
> 
> Fine! :-) (Front-end? Or back-end?)

The front-end definitely is (read: we can use this for GPC); for the
back-end it *might* be necessary to convert references to pointers.
No big deal.

> gpc will certainly not remove objects when classes are implemented. :-)

It won't. :-)

According to Frank Heckenbach:
> According to The African Chief:
> >    New(Foo);
> >    Foo.Create;
> 
> If it's undefined in Delphi, it wouldn't hurt if there is a defined
> behaviour in gpc. :-)

You cannot `New' a class because it is a reference, no pointer.
The above should be a syntax error in GPC as well as in Delphi.

> My suggestion: implement a compiler switch like '--base-class="TObject"' so
> that gpc will use this class by default as a parent class if no parent is
> declared (and, of course, if the current class is not "TObject" itself ;-).
> With "--delphi", this switch could be set automatically. Then, TObject could
> be declared in some unit (like System for Delphi). (For "completeness", we
> could also have '--base-object' or so...)

Sounds reasonable.

> BTW: This is similar to the '--uses="system"' I suggested -- things that
> are not really the job of the compiler, but needed for compatibility. Such
> switches seem to make the difference to the compiler as small as possible.

Sounds reasonable.  (Even *more* switches!)

> For BP/Delphi programs that are just recompiled with gpc, these switches
> can be used. When the programs are really ported to gpc, these things would
> probably put into them programs themselves, and the switches would not be
> used anymore (neither for native gpc programs), I guess.

That's the anti-motivating part of compatibility:  All this is intended *not*
to be used.

> > Like I said, "Create" and "Destroy" are empty in TObject
> > (i.e., they contain just an empty "begin end;" block).
> > "Free" checks whether the pointer is Nil, and if it is not,
> > it calls Destroy.
> 
> Nice little "trick", but not very systematic. "Free" is a method of an
> object, and this object can be "nil^"!? Technically, it works, but "Free"
> must not be virtual (I guess it isn't in Delphi)! But as a clean way, I'd
> prefer a procedure... (Or should we regard it as defined behaviour to call
> a static method of a non-existing object if the method doesn't access any
> fields of the object?)

Sorry, but this nice little trick is purest brain-damage!

I saw similar tricks in Turbo Vision.  All of this works, but it relies on
how the compiler and the RTS do things.

  - Dereferencing a `Nil' pointer should yield a runtime error.  Both BP
    and GPC don't check this, but this is a bug in the compiler to be
    eliminated when we implement runtime checks into GPC.

  - Releasing the storage of an object while a method of it is running
    is idiocy.  It should yield a runtime error, too, but this is too
    hard to detect for the compiler.

Greetings,

    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 [970624] - http://home.pages.de/~gnu-pascal/ [970125]

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