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