[<<Previous Entry]
[^^Up^^]
[Next Entry>>]
[Menu]
[About The Guide]
VAR...[IS...] IN
Synopsis
Control multiply inherited variables
Syntax
VAR <variable name> [IS <original name>]
IN <ancestor class>
Arguments
<variable name> is the name that the variable will have in the
current class.
<original name> is the name of an inherited variable (a
variable defined in an ancestor class) which the declared variable
will be mapped to. This argument should be omitted if its value is
the same as <variable name>.
<ancestor class> is the name of the class which contains the
original message. This argument is only required in multiply
inherited classes.
Description
If a multiply inherited class inherits a variable with the same
name from two different classes, one will always override the
other. This command can be used to specify that such a variable
should be inherited from a class other than the default, or given
a different name in the subclass being defined.
Specifying a class other than the default from which to inherit a
variable is probably only useful if the variable has been defined
with qualifications, such as a TYPE or CLASS restriction.
Specifying an alternative name for a multiply inherited variable
will only help to resolve name conflicts if the variable is not
used in an ancestor class.
Example
Assume that a class named BordTextWindow is multiply inherited
from two classes named BorderedWindow and TextWindow as follows:
CREATE CLASS BorderedTextWindow ;
FROM TextWindow, BorderedWindow
// ...
By default, because it is listed first, variables inherited from
TextWindow will take precedence over variables of the same name
inherited from BorderedWindow. We can override the default
precedence as follows:
VAR x IN BorderedWindow
Assuming TextWindow also has a variable named x, the above
declaration will cause it to be overridden by the one inherited
from BorderedWindow. However, this does not necessarily solve all
problems caused by name conflicts. See the warning below for more
information.
In our example so far, special action (use of a scope resolution
message) would be required to access the x variable inherited from
TextWindow. To resolve this, we could define an alternative name
for x in the TextWindow class:
VAR x IN BorderedWindow // as above
VAR textX IS x IN TextWindow
This provides a convenient way to access both methods. Of course,
we could have achieved something similar the other way around:
MESSAGE bordX IS x IN BorderedWindow
This relies on the fact the default x would be inherited from
TextWindow, and defines an alternative name (bordX) for the other
x variable, inherited from BorderedWindow.
Warning
In the first part of the example above, x was defined so that it
would refer to the x variable defined in BorderedWindow, instead
of the one defined in TextWindow. However, this can lead to a
problem if x is used in any of the methods defined in TextWindow,
or other ancestor classes. When these variables are accessed via
an instance of BordTextWindow, the variable defined in
BorderedWindow will be accessed. This is unlikely to be the
behavior expected by the methods in TextWindow, and usually leads
to serious problems.
For this reason, it is best to use the VAR...[IS...] IN
command to redefine variables which are not used in the class in
which they are originally defined. See Multiple Inheritance
for more information.
See Also
MESSAGE...[IS...] IN, Multiple Inheritance
See Also:
MESSAGE...[IS...] IN
Multiple Inheritance
This page created by ng2html v1.05, the Norton guide to HTML conversion utility.
Written by Dave Pearson