For a single inheritance class, there is only one reasonable way to order the class inheritance path: it lists the class itself, its parent, it's parent's parent, and so on, culminating in the root class.
For example, consider first the following single inheritance class hierarchy:
The figure shows several classes in a hierarchy based on
EQUIPMENT. Arrows point from the superior classes to the subclasses. The structure of the hierarchy is:
EQUIPMENTis a subclass of
OBJECTas its direct superior class)
COMPUTERare two subclasses of
EQUIPMENTas its direct superior class)
PCare subclasses of
OBJECTwill be omitted from class inheritance paths from this point on, because they would be exactly the same in every one.
When you reset a KB, attribute values do not return to their default values: they keep the values that they had prior to the reset. This behavior distinguishes default values of attributes from initial values of variables and parameters, which are restored each time a KB is reset.
For example, consider the following hierarchy:
The figure shows the same classes that we looked at earlier. Two of the classes,
PERIPHERAL, explicitly define icons, A picture of each icon appears by the class that defines it. The icon by
EQUIPMENT is called the "workstation icon." The icon by
PERIPHERAL is called the "node icon."
Icon-description attribute of its class description. This is a system-defined attribute that has a default value provided by G2. A user-defined class can override this default by specifying its own value for
PERIPHERAL both do.
Icon-description values shown, an instance of
EQUIPMENT has a workstation icon, because the class defines that default value for the attribute. An instance of
COMPUTER has the same icon, because
COMPUTER inherits the default value from
PC similarly inherits that default value from
COMPUTER, so a
PC instance also has the workstation icon.
PERIPHERAL explicitly specifies a different default
Icon-description value: the node icon. This definition shadows
EQUIPMENT's default icon description, and is inherited by
NETWORK. Thus instances of both
NETWORK have node icons, not workstation icons.
Inheriting Default Values for Stubs
Icons and stubs are closely related, but they are specified by two different attributes of a definition. This independence could result in mismatched icons and stubs, so the G2 class inheritance rules contain a special provision that prevents it.
Inheritance of Methods
A given class can have any number of associated methods that define the behavior of instances of the class. These methods can take arguments that tailor the behavior to suit the particular instance. Methods defined for different classes can have the same name.
Class-inheritance-path of that class and uses the first explicitly defined method it encounters that has the same number of arguments as the calling expression. If no match is found with any class in the class inheritance path, G2 signals an error.
To facilitate modular design and encapsulation, G2 allows a subclass to define an attribute whose name duplicates that of an inherited user-defined attribute. Instances of the subclass then have both the inherited attribute and the locally defined attribute. G2 does not permit a user-defined attribute to duplicate the name of a system-defined attribute.
Naming Duplicate Attributes
To prevent ambiguity, G2 qualifies the names of duplicate attributes as needed with the name of the class that defines each attribute. The syntax for a qualified attribute name is:
Suppose that both
COMPUTER explicitly define an attribute named
Application. The table of a
COMPUTER instance would show two attributes:
Application, representing the locally defined attribute, and
Equipment::Application, representing the inherited attribute.
An instance of
PC has the same
Application attributes as an instance of
COMPUTER, because the
PC class inherits them from the
In the preceding two tables, the default
Application attribute is the same for both
PC: it is
PC's attribute. The reason is that, for both
COMPUTER is the first class on the class's inheritance path to define an
PC also explicitly defined an
Application attribute, an instance of
PC would have three such attributes:
The attribute now named
Computer::Application is the same attribute that was named
PC defined its own
Application attribute. It is no longer
Application attribute, because
Application definition is now the first such definition by a class on
PC's inheritance path.
Referencing Duplicate Attributes
When you reference one of a set of duplicate attributes, you must qualify the reference as needed to specify the correct attribute. The name for any attribute of an item appears with the necessary qualification in the item's table.
pc-1 is an instance of
PC in the
EQUIPMENT hierarchy pictured above, then:
The meaning of an unqualified name can change if the hierarchy changes. For example, if
PCwere to define its own
PCitself defines. To reference computer's
Applicationattribute, you would need a qualified name:
Applicationattribute of its own.
When you give a qualified name in a reference, G2 always does the same thing: it uses the default attribute of the class named in the reference. Thus a qualified reference need not name the class that actually defines the attribute.
For example, in the hierarchy shown previously on the
MULT-DEFS-WSworkspace, the names
Equipment::Applicationall refer to
Applicationattribute, because that is the default
Applicationattribute for all three classes.
Be careful not to define a duplicate attribute when all you want to do is shadow an inherited attribute's default value. You can define a new default value for any attribute in any class definition, as described under Specifying Default Values for Inherited Attributes.