Inheritance documentation

Forum for discussion about the documentation project.
counting_pine
Site Admin
Posts: 5902
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Postby counting_pine » Sep 15, 2012 20:34

fxm wrote: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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Sep 15, 2012 21:14

counting_pine wrote:
fxm wrote: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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 08, 2012 14:08

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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 16, 2012 17:24

Page "Virtual" wrote: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.

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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 16, 2012 19:49

Page "Abstract" wrote:Abstracts are called "pure virtual" in C++, and unlike FreeBASIC, C++ allows pure virtuals to have a body.

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.
Last edited by fxm on Nov 17, 2012 9:46, edited 1 time in total.
dkl
Site Admin
Posts: 3191
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Inheritance documentation

Postby dkl » Nov 16, 2012 20:44

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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 16, 2012 21:02

Page "Virtual" wrote: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.

As a result, to remove all doubt, we could also add that a constructor cannot call a virtual method.
fxm
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 17, 2012 14:28

dkl wrote:... 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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Nov 27, 2012 13:00

dkl wrote: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
Site Admin
Posts: 5902
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Postby counting_pine » Nov 27, 2012 15:08

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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Dec 18, 2012 15:52

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
Posts: 3329
Joined: Dec 06, 2009 22:27
Location: N47°, E15°

Re: Inheritance documentation

Postby TJF » Dec 18, 2012 19:12

fxm wrote: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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Dec 19, 2012 15:01

TJF wrote:
fxm wrote: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
Site Admin
Posts: 5902
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Inheritance documentation

Postby counting_pine » Dec 20, 2012 20:46

fxm wrote: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
Posts: 7896
Joined: Apr 22, 2009 12:46
Location: Paris suburb, FRANCE

Re: Inheritance documentation

Postby fxm » Dec 22, 2012 20:19

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.

Return to “Documentation”

Who is online

Users browsing this forum: No registered users and 1 guest