Inheritance documentation
Re: Inheritance documentation
We can use "shadowing" to describe a local identifier taking precedence over one from a parent scope/namespace.
Re: Inheritance documentation
For example if I wanted to clarify this sentence of documentation:
A static method cannot override a virtual/abstract method.
'A derived static method cannot override a base virtual/abstract method, but can override any base method' appears to be contradictory.
I prefer:
'A derived static method cannot override a base virtual/abstract method, but can redefine or even hide (when derived member is not public) any base method'.
In that case, I think that 'redefine or hide' is more explicit for user that 'shadow'.
A static method cannot override a virtual/abstract method.
'A derived static method cannot override a base virtual/abstract method, but can override any base method' appears to be contradictory.
I prefer:
'A derived static method cannot override a base virtual/abstract method, but can redefine or even hide (when derived member is not public) any base method'.
In that case, I think that 'redefine or hide' is more explicit for user that 'shadow'.
Re: Inheritance documentation
dkl wrote:We can use "shadowing" to describe a local identifier taking precedence over one from a parent scope/namespace.
Yes dkl at final, why not?fxm wrote:In that case, I think that 'redefine or hide' is more explicit for user that 'shadow'.
'redefine' may also sound like 're-implement'!
Previous sentence reworded, by using "shadow":
'A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract)'.
Re: Inheritance documentation
Proposition of documentation rewording (using shadowing and overriding)
- KeyPgExtends:
... Fields and methods inherited from base_typename will be implicitly accessible like regular members of typename.However, regular members will override inherited members if they have the same identifier. However, a regular member will shadow an inherited member if they have the same identifier.
- KeyPgBase:
...Base is especially useful when local variables or members of a derived type override a base type's members by using the same identifiers. Base is especially useful when a base type's member is shadowed by a local variable or member of a derived type using the same identifier. Base then allows unambiguous access to the base type.
- KeyPgVirtual:
...A static method cannot override a virtual/abstract method. A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract).
- KeyPgAbstract:
...A static method cannot override a virtual/abstract method. A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract).
- KeyPgExtends:
... Fields and methods inherited from base_typename will be implicitly accessible like regular members of typename.
- KeyPgBase:
...
- KeyPgVirtual:
...
- KeyPgAbstract:
...
Re: Inheritance documentation
New wiki page: OVERRIDE
How highlight that 'Override' can be also used in declarations for properties (get and set) and destructor?
Should we add specific lines in §'Syntax', or only note it in the §'Description'?
[Edit]
OK, thanks dkl.
How highlight that 'Override' can be also used in declarations for properties (get and set) and destructor?
Should we add specific lines in §'Syntax', or only note it in the §'Description'?
[Edit]
OK, thanks dkl.
Last edited by fxm on Dec 27, 2012 10:51, edited 2 times in total.
Re: Inheritance documentation
Fixed, I just added Operator|Property|Destructor to the line, showing clearly. Hopefully it shows that Override can be used at the end of such method declarations, and in case of functions, it goes behind the AS TYPE part.
Re: Inheritance documentation
Perfect!dkl wrote:Fixed, I just added Operator|Property|Destructor to the line, showing clearly. Hopefully it shows that Override can be used at the end of such method declarations, and in case of functions, it goes behind the AS TYPE part.
Operator?
Is there still hope to be virtual (at least 'Cast' and 'Let')?
[Edit]
Thanks dkl, I saw the new commit Add overriding and vtable lookups for virtual operators.
Last edited by fxm on Dec 27, 2012 7:55, edited 1 time in total.
Re: Inheritance documentation
Now that the new wiki page Override is created by defining its precise meaning, I think I should rename all other 'Override' misleading, as proposed above!fxm wrote:Proposition of documentation rewording (using shadowing and overriding)
- KeyPgExtends:
... Fields and methods inherited from base_typename will be implicitly accessible like regular members of typename.However, regular members will override inherited members if they have the same identifier.However, a regular member will shadow an inherited member if they have the same identifier.
- KeyPgBase:
...Base is especially useful when local variables or members of a derived type override a base type's members by using the same identifiers.Base is especially useful when a base type's member is shadowed by a local variable or member of a derived type using the same identifier. Base then allows unambiguous access to the base type.
- KeyPgVirtual:
...A static method cannot override a virtual/abstract method.A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract).
- KeyPgAbstract:
...A static method cannot override a virtual/abstract method.A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract).
{Edit]
Done.
Last edited by fxm on Dec 26, 2012 19:29, edited 1 time in total.
Re: Inheritance documentation
Thanks for the clear examples. A virtual and abstract methods in the next version of the compiler will be? And is not it time to call the version freebasic 1.0??? Compilier still powerful and stable at least under windows
Re: Inheritance documentation
As proposed by D.J.Peters, I added my "all in one" example in the following documentation page:
KeyPgExtends ⇒ FxMwikki [Added: Example using all eight keywords of inheritance]
KeyPgExtends ⇒ FxMwikki [Added: Example using all eight keywords of inheritance]
Re: Inheritance documentation
For numerous examples in the documentation, there is a 'Sleep' at the end of the program to automatically stop the window closing, allowing user to see at final the data returned without having to add himself 'Sleep' at the end of the copied program.counting_pine wrote:KeyPgExtends ⇒ CountingPine [I don't think we use Sleep at the end of official examples unless necessary.]
That is also true for this program where the final screen synthetizes the program meaning:
Code: Select all
Name: Object (real): Hierarchy:
Mouse animal Object(forRTTI) <- root <- animal
Buddy dog Object(forRTTI) <- root <- animal <- dog
Tiger cat Object(forRTTI) <- root <- animal <- cat
animal destructor: Mouse
root destructor
dog destructor: Buddy
animal destructor: Buddy
root destructor
cat destructor: Tiger
animal destructor: Tiger
root destructor
So, must we hunt 'Sleep' everywhere in the documentation?
-
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: Inheritance documentation
Not everywhere. There are some good use cases for Sleep in the documentation, e.g. to show how it's used, or to stop a graphics window automatically closing.
Perhaps the time should be taken to remove all the unnecessary Sleeps, but I'm not going to tell anyone to do that..
Why should Sleep not be added to the end of every example? Because it's just a kludge that's used to overcome the shortcomings of FbEdit and FBIde - of which the latter already has a Sticky'd method of working around this.
For people who don't have this shortcoming, e.g. Geany users or people who run from a command line, the Sleep is a nuisance. It keeps the program open without hinting why. And it adds an unnecessary extra line of clutter for people who are just reading through the code in the documentation without trying to compile or run it.
I don't want to convey the idea that the canonical FB program has a Sleep at the end, and putting it on wiki examples lends this an "official" air.
Perhaps the time should be taken to remove all the unnecessary Sleeps, but I'm not going to tell anyone to do that..
Why should Sleep not be added to the end of every example? Because it's just a kludge that's used to overcome the shortcomings of FbEdit and FBIde - of which the latter already has a Sticky'd method of working around this.
For people who don't have this shortcoming, e.g. Geany users or people who run from a command line, the Sleep is a nuisance. It keeps the program open without hinting why. And it adds an unnecessary extra line of clutter for people who are just reading through the code in the documentation without trying to compile or run it.
I don't want to convey the idea that the canonical FB program has a Sleep at the end, and putting it on wiki examples lends this an "official" air.
Re: Inheritance documentation
Agreed. Well spoken!counting_pine wrote:For people who don't have this shortcoming, e.g. Geany users or people who run from a command line, the Sleep is a nuisance. It keeps the program open without hinting why. And it adds an unnecessary extra line of clutter for people who are just reading through the code in the documentation without trying to compile or run it.
I don't want to convey the idea that the canonical FB program has a Sleep at the end, and putting it on wiki examples lends this an "official" air.
Re: Inheritance documentation
'Sleep' as final line in documentation examples is only useful for all new beginners, when there is something to check before automatic window closing.
There is no command 'SELECT ALL' or the equivalent for the program examples in the documentation, as it is in the forum to help to the complete copy of the program.
When the user must manually select with the mouse the corresponding block to the program example inside the documentation page, it can then easily stop just before the final line "Sleep".
There is no command 'SELECT ALL' or the equivalent for the program examples in the documentation, as it is in the forum to help to the complete copy of the program.
When the user must manually select with the mouse the corresponding block to the program example inside the documentation page, it can then easily stop just before the final line "Sleep".
Re: Inheritance documentation
Not everyone is using FbEdit, FBIde, or Geany, or working from the command line. For an app that would otherwise close immediately a Sleep will work for everyone, but leaving it off will not.counting_pine wrote: Why should Sleep not be added to the end of every example? Because it's just a kludge that's used to overcome the shortcomings of FbEdit and FBIde - of which the latter already has a Sticky'd method of working around this.
For people who don't have this shortcoming, e.g. Geany users or people who run from a command line, the Sleep is a nuisance.