Inheritance documentation

[counting_pine]

If a 'Constructor(Byref As Parent)' is defined in the base-type 'Parent', we can replace:
Cast(Parent, This) = rhs
with:
Base.Constructor(rhs)

You'd have to put base.destructor() before it.
I think the only case where a .constructor() doesn't require an explicit .destructor() is for the initialisation of fields that have been marked as = any in the type declaration. I think that's something we'd want to do better if we could find a good syntax for it.

Without direct access to the base, the cast-to-parent is the best solution.
Presumably this situation also occurs for any operator, not just assignments. I don't think constructor hacks can't be used in the same way there.

[fxm]

If a 'Constructor(Byref As Parent)' is defined in the base-type 'Parent', we can replace:
Cast(Parent, This) = rhs
with:
Base.Constructor(rhs)

You'd have to put base.destructor() before it.

Yes, you are right, because otherwise, the old members (as the objects / pseudo-objects) are not destroyed.

[fxm]

The 'OFFSETOF' page of documentation does not take into account the inheritance.
The present definition concerns only the not derived types.

Documentation updated:
KeyPgOffsetof ⇒ FxMwikki [Update to take into account inheritance]
Feel free to improve the modified text.

[fxm]

[quote="Page "Virtual""]When calling virtual methods, the compiler may need to do a vtable lookup in order to find out which method must be called for a given object. This requires an extra hidden vtable pointer field to be added at the top of each Type with virtual methods. This hidden vptr is provided by the built-in Object type. Because of that, virtual methods can only be declared in Types that directly or indirectly extend Object.[/quote]
dkl,

Perhaps it would be best balanced by having the same level of detailed explanation at page "Is Operator (Run-Time Type Information)" where I think the hidden vptr is also used, or else by grouping all the 'vtable' explaination at page "Object" which is linked to these two previous pages!

[fxm]

[quote="Page "Abstract""]Abstracts are called "pure virtual" in C++, and unlike FreeBASIC, C++ allows pure virtuals to have a body.[/quote]
dkl,

Should we really emphasize this end of sentence in bold?
A pure virtual function in C++ having a body is a very particular case and little used because this body cannot be called dynamically (using vtable informations) but only statically with the '<class name>::<function name>' calling form (this is not a body implementation by default).
Derived classes that implement this pure virtual function may statically call this implementation somewhere in their code. If part of the code of two different derived classes is similar then it may make sense to move it up in the hierarchy, even if the function should be pure virtual.

[dkl]

I wanted to highlight the similarity of FB abstracts and C++ pure virtuals but also state that there are differences. However that part should probably be removed again, because it doesn't really help document FB's behaviour. (and if comparing to C++, then why not other languages too, etc.)

I think it's ok to keep the vtable lookup "details" on the Virtual page; it answers the question "why can virtuals only be used in UDTs that extend Object". We could add similar notes regarding the vptr on the Operator Is and Object pages, yes. It explains the reason for having Object. It's a technical detail but I think these kind of things need to be mentioned in the documention nonetheless, although preferably at the bottom, not in the first paragraph.

[fxm]

[quote="Page "Virtual""]Constructors can not be Virtual, because an object (more specifically its hidden vptr) must be initialized first before it is possible to do calls to that object's virtual methods. Such virtual calls require the vptr for the before-mentioned vtable lookup, however the vptr initialization is only done at the top of a Type's constructors, thus the constructor must be executed first, before any virtual method calls.[/quote]
As a result, to remove all doubt, we could also add that a constructor cannot call a virtual method.

[fxm]

... We could add similar notes regarding the vptr on the Operator Is and Object pages, yes. It explains the reason for having Object...

I think it's just you who has the ability to do so.

[fxm]

I think it's ok to keep the vtable lookup "details" on the Virtual page; it answers the question "why can virtuals only be used in UDTs that extend Object". We could add similar notes regarding the vptr on the Operator Is and Object pages, yes. It explains the reason for having Object. It's a technical detail but I think these kind of things need to be mentioned in the documention nonetheless, although preferably at the bottom, not in the first paragraph.

With my limited knowledge of polymorphism and English, I did what I could to complement gradually the following pages (the most important for user):
EXTENDS
OBJECT
Operator Is (Run-time type information)
VIRTUAL
ABSTRACT

dkl, counting_pine, feel free to improve that!

[counting_pine]

Good work so far.
I can't help feeling that we need to rethink some style decisions on some pages like this.
We have a lot of non-monospaced links, perhaps to imply we're talking more about the concept than the period. But in that case I think we need only link to it once. And we could remove all the bold in the case of non-keyword self-refs.
But some of this could also just be changed to monospace keyword links I think.

I also think we should perhaps call Types UDTs or something - the use of Type as an standalone "thing" doesn't sit that comfortably. Particularly if we're not talking specifically about the keyword.

Also, do we need to explain on a technical level why a constructor can't be virtual? It seems to me to be a fundamental concept, that the type of the object - and therefore the constructor called - is dictated by the code.
It might suffice just to say that constructors cannot be virtual. Anyone wondering why should immediately be faced with the question of why he/she would want one, and what they would do if they did work.

[fxm]

dkl has introduced a new attribute called "Override" that allows you to explicitly mark methods you intend to be overrides. If the method is not an override, the compiler will complain about it: "error 207: Not overriding any virtual method".

Should we create a new page in the documentation, or only just report it in the "KeyPgVirtual" as is presently the case for "Explicit" in the "KeyPgEnum"?

[TJF]

Should we create a new page in the documentation, or only just report it in the "KeyPgVirtual" as is presently the case for "Explicit" in the "KeyPgEnum"?

A new keyword needs an entry in the alphabetical list and I think it should have an own page with links to the mentioned sites.

[fxm]

Should we create a new page in the documentation, or only just report it in the "KeyPgVirtual" as is presently the case for "Explicit" in the "KeyPgEnum"?

A new keyword needs an entry in the alphabetical list and I think it should have an own page with links to the mentioned sites.

The 'Explicit' keyword (qualifier for 'Enum') which has not its own page, is the only case I know, but I can not be sure that there is no other, seen the extent of documentation. counting_pine knows it probably a lot better!

[counting_pine]

counting_pine knows it probably a lot better!

I think there are a couple of documentation pages still unimplemented just because of the headache of ticking all the necessary boxes, writing the page, making all the necessary links (and a few unnecessary ones). But they would still be good to have.

[fxm]

Now after the addition of 'virtual' method, the documentation is IMHO a little ambiguous because the 'override' term is used for two different things:
- When a derived member redefines a base member.
- When a derived member method implements a virtual/abstract base member method (by polymorphism).

I proposed to reserve the 'override' term for polymorphism only, otherwise to use 'redefine' or even 'hide' (when derived member is not public) for simple inheritance.

What is your opinion?
If agreed, I can update the documentation about it.