Delphi classes (Was: bugs, incompatibity, function attributes)

Thu, 3 Jul 1997 01:13:18 +0200

The African Chief wrote:

> >Sounds reasonable.  So should we just change "asmname" to "name"?
> >Or keep both?
>
> I think we should keep both. "Asmname" is intuitive, but
> "name" is good for Delphi compatibility.

Besides, removing "asmname" would break some existing programs (including
a published one of mine)...

> 2. [a] a Class instance becomes a pointer to the class;
>     (or is it that the Class itself is a pointer to an object/class?);

I think the latter would be a more consistent interpretation (at least for
us, even if Delphi does it otherwise). So "class" = "pointer to object",
approximately...

> 	e.g.,  "Var Foo : MyFoo"
> 	=       "Var Foo : ^MyFoo" in the current OOP model

Saves declaring those "PFoo" types, OTOH makes it impossible to declare
global or local objects variables (without the overhead of allocating
memory). If we have objects and classes, the programmer can choose what
(s)he prefers.

>    [b] the constructor does the heap allocation stuff,
> 	e.g., "Foo := MyFoo.Create"
> 		*allocates memory for Foo "(New, Foo)"
> 		*calls Foo^.Create (constructor)

So it's the same as "Foo := New(MyFoo, Create)" in BP? Why not!
Shorter to type, perhaps easier to read (once one gets used to not looking
for "New").

What about destructors? Does Delphi still use "Dispose", or has it another
syntax too, or does it dispose of objects automatically. (C++, BTW, does the
latter. It destroys e.g. local objects at the end of the function
automatically. This is possible because in C++ every class has exactly one
destructor. I guess they set the pointer to nil automatically at the
beginning (and set it back to nil if the destructor is called manually),
so they can easily find all local objects that "exist" and destroy them.)

> 		*Foo now points to whatever
>                        "Foo.Create" - should generate an exception
>                        because Foo needs to be assigned to the
> 	       constructor

AFAICS, calling a second constructor does not even have to be forbidden --
at least in gpc. Constructors can be called like normal methods from an
initialized object, though this is certainly uncommon practice.

>    [c] deference it automatically;
> 	e.g., "Foo.Bar := 12" (instead of "Foo^.Bar := 12")

This reminds me of C++'s "reference types" (not only for objects, but for
any types). I.e., a pointer internally, but dereferenced automatically when
necessary. I think they could be quite useful sometimes, anyway, and if
they'll be implemented (syntax?), we'd have "class" = "reference to
object"...

> 3.  Allow virtual constructors (or at least, don't reject the
> "virtual" directive in a "Class" constructor's definition)

AFAIK, this is planned, anyway.

> 4.  Virtual methods to be overridden must be overriden
> with the "override" directive; the "virtual" directive merely
> creates a new method (or at least, don't reject the
> "override" directive in a "Class" definition)

Does this mean you have to use "virtual" for *every* method in Delphi, or
what is meant by "create a new method"?

> 5. Allow "Published" methods (or at least, don't reject the
> "published" directive in a "Class" definition).

Is this the same as "public" in C++ (= visible to everyone)? I, personally,
would prefer "public", "protected" (=visible only to descendants) and
"private" (=visible only to the type/class itself -- BTW, BP does it a bit
differently, and extend the visibility of private methods to the whole unit
it's declared in. I don't see any reason or advantage of this). So, perhaps
we could allow all those keywords, including "published", in any order, also
possibly repeated (unlike BP).

> 6. All classes to have the same ultimate ancestor object.

The same discussion as with objects recently... ;-)
Is this really necessary (if so, for what?), or is it sufficient if all
classes in a given library use the same ancestor by convention?
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)