Revision history for KeyPgAbstract


Revision [22729]

Last edited on 2019-06-26 12:50:09 by fxm [added 'Extends Zstring' and 'Extends Wstring' links]
Additions:
- ##[[KeyPgExtendsZstring|Extends Zstring]]##
- ##[[KeyPgExtendsWstring|Extends Wstring]]##

Revision [21548]

Edited on 2016-08-14 02:42:11 by fxm [Added link to Override]
Additions:
- ##[[KeyPgOverride|Override]]##

Revision [20817]

Edited on 2016-03-12 14:41:18 by fxm [Formatting]

No Differences

Revision [20040]

Edited on 2016-02-10 15:54:18 by DkLwikki [Update link format]
Additions:
[[KeyPgType|Type]] //typename// [[KeyPgExtends|Extends]] //base_typename//
[[KeyPgDeclare|Declare]] **Abstract** [[KeyPgSub|Sub]]|[[KeyPgFunction|Function]]|[[KeyPgProperty|Property]]|[[KeyPgOperator|Operator]] ...
End [[KeyPgType|Type]]
##**Abstract**## is a special form of ##[[KeyPgVirtual|Virtual]]##. The difference is that abstract methods do not have a body, but just the declaration. Essentially this allows the declaration of an interface which can be implemented by various derived types.
[[KeyPgConstructor|Constructors]] cannot be abstract, since they cannot be virtual. In addition, abstract [[KeyPgDestructor|destructors]] are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared ##**Abstract**##, ##[[KeyPgVirtual|Virtual]]## or normal (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> normal, from top to bottom of the inheritance hierarchy.
The access control (##[[KeyPgVisPublic|Public]]##/##[[KeyPgVisProtected|Protected]]##/##[[KeyPgVisPrivate|Private]]##) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.
- Only available in the //[[CompilerOptlang|-lang fb]]// dialect.
- ##[[KeyPgVirtual|Virtual]]##
- ##[[KeyPgType|Type]]##
- ##[[KeyPgExtends|Extends]]##
- ##[[KeyPgObject|Object]]##
Deletions:
[[KeyPgType Type]] //typename// [[KeyPgExtends Extends]] //base_typename//
[[KeyPgDeclare Declare]] **Abstract** [[KeyPgSub Sub]]|[[KeyPgFunction Function]]|[[KeyPgProperty Property]]|[[KeyPgOperator Operator]] ...
End [[KeyPgType Type]]
##**Abstract**## is a special form of ##[[KeyPgVirtual Virtual]]##. The difference is that abstract methods do not have a body, but just the declaration. Essentially this allows the declaration of an interface which can be implemented by various derived types.
[[KeyPgConstructor Constructors]] cannot be abstract, since they cannot be virtual. In addition, abstract [[KeyPgDestructor destructors]] are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared ##**Abstract**##, ##[[KeyPgVirtual Virtual]]## or normal (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> normal, from top to bottom of the inheritance hierarchy.
The access control (##[[KeyPgVisPublic Public]]##/##[[KeyPgVisProtected Protected]]##/##[[KeyPgVisPrivate Private]]##) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.
- Only available in the //[[CompilerOptlang -lang fb]]// dialect.
- ##[[KeyPgVirtual Virtual]]##
- ##[[KeyPgType Type]]##
- ##[[KeyPgExtends Extends]]##
- ##[[KeyPgObject Object]]##

Revision [16826]

Edited on 2013-06-06 13:41:26 by CountingPine ["constructors"/"destructors" isn't a keyword; "can not" -> "cannot"]
Additions:
[[KeyPgConstructor Constructors]] cannot be abstract, since they cannot be virtual. In addition, abstract [[KeyPgDestructor destructors]] are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
Deletions:
##[[KeyPgConstructor Constructors]]## can not be abstract, since they cannot be virtual. In addition, abstract ##[[KeyPgDestructor destructors]]## are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.

Revision [16824]

Edited on 2013-06-03 20:02:03 by AgSwikki ["constructors"/"destructors" isn't a keyword; "can not" -> "cannot"]
Additions:
##[[KeyPgConstructor Constructors]]## can not be abstract, since they cannot be virtual. In addition, abstract ##[[KeyPgDestructor destructors]]## are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
Deletions:
##[[KeyPgConstructor Constructor]]##s can not be abstract, since they cannot be virtual. In addition, abstract ##[[KeyPgDestructor destructor]]##s are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.

Revision [16648]

Edited on 2013-03-12 01:49:07 by CountingPine [UDT methods only available in lang fb]
Additions:
- Only available in the //[[CompilerOptlang -lang fb]]// dialect.
Deletions:
- Not available in the //[[CompilerOptlang -lang qb]]// dialect unless referenced with the alias ##**""__Abstract""**##.

Revision [16521]

Edited on 2013-01-01 10:48:09 by FxMwikki [Replaced the qualifier "regular" by "normal" to refer to a non-virtual function (neither abstract)]
Additions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared ##**Abstract**##, ##[[KeyPgVirtual Virtual]]## or normal (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> normal, from top to bottom of the inheritance hierarchy.
Deletions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared ##**Abstract**##, ##[[KeyPgVirtual Virtual]]## or regular (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the inheritance hierarchy.

Revision [16519]

Edited on 2012-12-27 09:54:09 by CountingPine [Link to Public:/... pages]
Additions:
The access control (##[[KeyPgVisPublic Public]]##/##[[KeyPgVisProtected Protected]]##/##[[KeyPgVisPrivate Private]]##) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.
Deletions:
The access control (##Public##/##Protected##/##Private##) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.

Revision [16516]

Edited on 2012-12-26 13:26:22 by FxMwikki [Rename 'overriding' when misleading by using 'shadowing']
Additions:
A derived static method cannot override a base virtual/abstract method, but can shadow any base method (including virtual/abstract).
Deletions:
A static method cannot override a virtual/abstract method.

Revision [16499]

Edited on 2012-12-25 09:17:35 by FxMwikki [Reworded the comparison with "pure virtual" in C++]
Additions:
Abstracts are called "pure virtual" in ""C++"" (unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body, but accessible only statically).
Deletions:
Abstracts are called "pure virtual" in ""C++"", and unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body.

Revision [16490]

Edited on 2012-12-08 16:06:15 by FxMwikki [Only types that implement all the abstract methods are allowed to create objects]
Additions:
As a result, only types that implement all the abstract methods are allowed to create objects. For the same reason, a constructor should not call an unimplemented method.
Deletions:
As a result, only types that implement all the abstract methods are allowed to create objects.

Revision [16489]

Edited on 2012-12-08 14:48:43 by FxMwikki [Only types that implement all the abstract methods are allowed to create objects]
Additions:
As a result, only types that implement all the abstract methods are allowed to create objects.

Revision [16486]

Edited on 2012-12-01 13:07:52 by CountingPine [Formatting, typo]
Additions:
##**Abstract**## is a special form of ##[[KeyPgVirtual Virtual]]##. The difference is that abstract methods do not have a body, but just the declaration. Essentially this allows the declaration of an interface which can be implemented by various derived types.
In order to call an abstract method, it must have been overridden and implemented by a derived data type, or else the program will abort.
##[[KeyPgConstructor Constructor]]##s can not be abstract, since they cannot be virtual. In addition, abstract ##[[KeyPgDestructor destructor]]##s are not supported either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared ##**Abstract**##, ##[[KeyPgVirtual Virtual]]## or regular (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the inheritance hierarchy.
The access control (##Public##/##Protected##/##Private##) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.
Deletions:
**Abstract** is a special form of [[KeyPgVirtual Virtual]]. The difference is that abstract methods do not have a body, but just the declaration. Essentially this allows the declaration of an interface which can be implemented by various derived types.
In order to call an abstract method, it must have been overridden and implemented by a derived [[KeyPgType Type]], or else the program will abort.
[[KeyPgConstructor Constructors]] can not be **Abstract**, since they cannot be [[KeyPgVirtual Virtual]], as explained on the [[KeyPgVirtual Virtual page]]. In addition, [[KeyPgDestructor destructors]] can not be **Abstract** either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the inheritance hierarchy.
The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.

Revision [16482]

Edited on 2012-11-28 08:51:22 by FxMwikki [Minor rewording]
Additions:
The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call at compile-time.
Deletions:
The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call.

Revision [16480]

Edited on 2012-11-26 04:10:02 by FxMwikki [In the Note: added sentence about polymorphism versus static method]
Additions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each inheritance hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the inheritance hierarchy.
The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call.
A static method cannot override a virtual/abstract method.
Deletions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call. A static method cannot override a virtual/abstract method.

Revision [16478]

Edited on 2012-11-26 03:12:39 by FxMwikki [In the Note: added sentence about polymorphism versus static method]
Additions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call. A static method cannot override a virtual/abstract method.
Deletions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call.

Revision [16476]

Edited on 2012-11-25 17:12:18 by FxMwikki [In the Note: added sentence about the polymorphism versus the access control of overriding method]
Additions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process, but only for the initial call.
Deletions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process.

Revision [16475]

Edited on 2012-11-25 16:57:48 by FxMwikki [In the Note: added sentence about the polymorphism versus the access control of overriding method]
Additions:
**Note:** In a multi-level inheritance, a same named method (same identifier and signature) can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy. The acces control (public/protected/private) of an overriding method is not taken into account by the internal polymorphism process.
Deletions:
**Note:** In a multi-level inheritance, an overridden method can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy.

Revision [16469]

Edited on 2012-11-24 07:41:45 by FxMwikki [Note about mixing of overridden method specifiers: Abstract, Virtual and regular (no specifier)]
Additions:
**Note:** In a multi-level inheritance, an overridden method can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When there is mixing of specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy.
Deletions:
**Note:** In a multi-level inheritance, an overridden method can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When mixed specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy.

Revision [16467]

Edited on 2012-11-24 04:44:34 by FxMwikki [Note about mixing of overridden method specifiers: Abstract, Virtual and regular (no specifier)]
Additions:
**Note:** In a multi-level inheritance, an overridden method can be declared **Abstract**, [[KeyPgVirtual Virtual]] or regular (without specifier) at each hierarchy level. When mixed specifiers, the usual order is abstract -> virtual -> regular, from top to bottom of the hierarchy.

Revision [16454]

Edited on 2012-11-17 16:49:38 by CountingPine [Uniform random number in range 1..3]
Additions:
select case( int( rnd( ) * 3 ) + 1 )
Deletions:
select case( cint( rnd( ) * 3 ) )

Revision [16450]

Edited on 2012-11-17 04:57:58 by FxMwikki [In example, randomizing factor increased to 3 to balance probability of getting each language]
Additions:
select case( cint( rnd( ) * 3 ) )
Deletions:
select case( cint( rnd( ) * 2 ) )

Revision [16443]

Edited on 2012-11-16 09:25:35 by FxMwikki [Error correction (no method body)]
Additions:
Abstracts are called "pure virtual" in ""C++"", and unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body.
Deletions:
Abstracts are called "pure virtual" in ""C++"", and unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body.
For member methods with ##**Abstract**## in their declaration, ##**Abstract**## can also be specified on the corresponding method bodies, for improved code readability.

Revision [16442]

Edited on 2012-11-16 09:02:04 by FxMwikki [Abstract is allowed in front of member method bodies, not just in the declaration]
Additions:
For member methods with ##**Abstract**## in their declaration, ##**Abstract**## can also be specified on the corresponding method bodies, for improved code readability.
Deletions:
##**Abstract**## is allowed in front of member method bodies, not just in the declaration (the coherence with declaration is checked by compiler). When the method body is far from the declaration, it may be suitable to have here the information.

Revision [16438]

Edited on 2012-11-16 08:53:43 by FxMwikki [Abstract is allowed in front of member method bodies, not just in the declaration]
Additions:
Abstracts are called "pure virtual" in ""C++"", and unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body.
##**Abstract**## is allowed in front of member method bodies, not just in the declaration (the coherence with declaration is checked by compiler). When the method body is far from the declaration, it may be suitable to have here the information.
Deletions:
Abstracts are called "pure virtual" in ""C++"", and unlike ""FreeBASIC"", ""C++"" allows pure virtuals to have a body.

Revision [16430]

Edited on 2012-11-16 07:53:20 by DkLwikki [new page for ABSTRACT]
Additions:
[[KeyPgConstructor Constructors]] can not be **Abstract**, since they cannot be [[KeyPgVirtual Virtual]], as explained on the [[KeyPgVirtual Virtual page]]. In addition, [[KeyPgDestructor destructors]] can not be **Abstract** either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.
Deletions:
[[KeyPgConstructor Constructors]] can not be **Abstract**, since they cannot be [[KeyPgVirtual Virtual]], as explained on the [[KeyPgVirtual Virtual page]]. In addition, [[KeyPgDestructor destructors can not be **Abstract** either, because a destructor body (no matter whether implicit or explicit) is needed in order to call base and field destructors.

Revision [16429]

The oldest known version of this page was created on 2012-11-16 07:52:46 by DkLwikki [new page for ABSTRACT]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki



sf.net phatcode