Questions
From Andrey
| Revision as of 06:58, 3 February 2006 Andrey (Talk | contribs) ← Previous diff |
Current revision Andrey (Talk | contribs) |
||
| Line 1: | Line 1: | ||
| - | Does overriding in owner class break strict type checking? No, because the signature of the function override must conform to the signature of the overridden function. The conformity is checked in the compile time. | + | ''Does overriding in owner class break strict type checking?'' No, because the signature of the function override must conform to the signature of the overridden function. The conformity is checked in the compile time. |
| - | Does the new overriding break encapsulation? No, because the override has the same access rights to the member as the owner class itself. | + | |
| - | Does it break the logic of the member's use by allowing arbitrary changes to its behavior? No, because only a virtual function can be overridden. The presence of a virtual function indicates the class was designed to allow change. | + | ''Does the new overriding break encapsulation?'' No, because the override has the same access rights to the member as the owner class itself. |
| - | Can the use of overriding in owner class lead to losing control over an already debugged and tested class? New overriding uses only the public interface of the member's class; hence its application is a use of the class, not its extension or modification. | + | |
| - | Is the desire to change an object's behavior without subclassing an indicator of a poor design? Yes - when the change in behavior is big enough to form a new class. When the change is minor, this is not the case. | + | ''Does it break the logic of the member's use by allowing arbitrary changes to its behavior?'' No, because only a virtual function can be overridden. The presence of a virtual function indicates the class was designed to allow change. |
| - | Some compilers use the knowledge of the exact type of an object to optimize a virtual method call. If methods of a class member can be overridden, the compiler can no longer count on the member’s exact type. This can lead to the generation of slower code. This is a very serious question, and losing this kind of optimization would be a big sacrifice. There are several ways to resolve this issue: | + | |
| + | ''Can the use of overriding in owner class lead to losing control over an already debugged and tested class?'' New overriding uses only the public interface of the member's class; hence its application is a use of the class, not its extension or modification. | ||
| + | |||
| + | ''Is the desire to change an object's behavior without subclassing an indicator of a poor design?'' Yes - when the change in behavior is big enough to form a new class. When the change is minor, this is not the case. | ||
| + | |||
| + | ''Some compilers use the knowledge of the exact type of an object to optimize a virtual method call. If methods of a class member can be overridden, the compiler can no longer count on the member’s exact type. This can lead to the generation of slower code.'' This is a very serious question, and losing this kind of optimization would be a big sacrifice. There are several ways to resolve this issue: | ||
| * The first method is to limit the depth of overriding to just one level, forbidding overriding the methods of a member’s members. The override will be in the same place as the member, and the compiler will know how to make an explicit call. | * The first method is to limit the depth of overriding to just one level, forbidding overriding the methods of a member’s members. The override will be in the same place as the member, and the compiler will know how to make an explicit call. | ||
| - | * The second way is to introduce another language keyword, something similar to volatile, to indicate that the compiler cannot count on knowing the exact member’s class. | + | * The second way is to introduce another language keyword, something similar to ''volatile'', to indicate that the compiler cannot count on knowing the exact member’s class. |
| - | * The third solution, which appeals to me the most, is to reuse an existing language keyword. I would like to use the qualifier virtual to indicate that the compiler cannot count on knowing the exact member’s class. I leave the question of what way is the best and what other solutions might be for further discussion. | + | * The third solution, which appeals to me the most, is to reuse an existing language keyword. I would like to use the qualifier ''virtual'' to indicate that the compiler cannot count on knowing the exact member’s class. I leave the question of what way is the best and what other solutions might be for further discussion. |
| ''Does overriding in owner class break legacy code?'' No, because it does not change the member's interface. The behavior of the member changes, and this change, provided that it preserves the type, is the purpose of polymorphism in general and overriding in owner class in particular. | ''Does overriding in owner class break legacy code?'' No, because it does not change the member's interface. The behavior of the member changes, and this change, provided that it preserves the type, is the purpose of polymorphism in general and overriding in owner class in particular. | ||
Current revision
Does overriding in owner class break strict type checking? No, because the signature of the function override must conform to the signature of the overridden function. The conformity is checked in the compile time.
Does the new overriding break encapsulation? No, because the override has the same access rights to the member as the owner class itself.
Does it break the logic of the member's use by allowing arbitrary changes to its behavior? No, because only a virtual function can be overridden. The presence of a virtual function indicates the class was designed to allow change.
Can the use of overriding in owner class lead to losing control over an already debugged and tested class? New overriding uses only the public interface of the member's class; hence its application is a use of the class, not its extension or modification.
Is the desire to change an object's behavior without subclassing an indicator of a poor design? Yes - when the change in behavior is big enough to form a new class. When the change is minor, this is not the case.
Some compilers use the knowledge of the exact type of an object to optimize a virtual method call. If methods of a class member can be overridden, the compiler can no longer count on the member’s exact type. This can lead to the generation of slower code. This is a very serious question, and losing this kind of optimization would be a big sacrifice. There are several ways to resolve this issue:
- The first method is to limit the depth of overriding to just one level, forbidding overriding the methods of a member’s members. The override will be in the same place as the member, and the compiler will know how to make an explicit call.
- The second way is to introduce another language keyword, something similar to volatile, to indicate that the compiler cannot count on knowing the exact member’s class.
- The third solution, which appeals to me the most, is to reuse an existing language keyword. I would like to use the qualifier virtual to indicate that the compiler cannot count on knowing the exact member’s class. I leave the question of what way is the best and what other solutions might be for further discussion.
Does overriding in owner class break legacy code? No, because it does not change the member's interface. The behavior of the member changes, and this change, provided that it preserves the type, is the purpose of polymorphism in general and overriding in owner class in particular.
