| Previous | Table of Contents | Next |
When a boolean attribute is mandatory, it seems redundant to display the attribute’s name as well as its value each time it
is displayed. The display of two pieces of information seems unnecessary for the representation of a variable that only has
two states. A shorthand is to display the attribute only if it is true, and to elide its representation if it is false. Further
to this, since the presence of the representation already denotes that the attribute’s value is true, it would be far more
efficient to simply display the name of the attribute. We call the use of such a name alone in the body of a class-instance
a keyword.
However, the use of keywords is restricted to attributes that are mandatory and do not contain more than one value. There
are only two states available to a keyword representation: present or absent. By contrast, an optional boolean has three plausible
states: true, false, and not defined. Attributes with more than one value obviously have even more than this, and as such
neither optional nor multiply-defined boolean attributes can be shortened to keywords.
In the absence of a default value for a mandatory single-valued boolean attribute, it is assumed to be false, and its name
will appear in the class instance header only if this is not the case (the value is true). This is also the case if a default
value of false is
explicitly configured for this attribute. (See 4.3.5, “Default Values.?) If, however, the
attribute is configured with a default value of true, then the tilde symbol ‘~’ is used before the attribute name keyword
to denote that its value is false, and the absence of the attribute name indicates a value of true.
Programming languages such as C++, Java, and Pascal represent various pieces of information other than an identifier in the
definition of methods or procedures. These can include the visibility of the method, or the return type of the method. Variables
displayed in this way are called adjectives, since they provide information about an object before it is declared, much like
an adjective describing a noun in the English grammar.
Adjectives in HUTN are similar to keywords, but are located differently within the representation of the class instance. Where
a keyword’s representation is expressed in the body, an adjective’s is placed directly before the name of the class in the
introduction of the declaration. There are two kinds of adjectives: boolean-valued attributes, and enumeration-valued attributes.
Like keywords, boolean-valued adjectives are restricted to single-valued mandatory boolean attributes, and the name of the
attribute (perhaps preceded by a tilde symbol) is used as the adjective. Enumeration-valued adjectives, however, use the enumeration
labels as the adjective. While boolean-valued adjectives are available by default, enumeration-valued adjectives must be configured.
The metaclass for configuring
enumeration-valued adjectives is EnumAdjectiveConfig (see 5.1.7,
“EnumAdjectiveConfig
?).
Like the identifying attribute of a class, an attribute that is represented as adjective, within the introduction of a class
instance, need not be shown again within the body of the class instance.
When one or more attributes are defined as adjectives on a class, the nature of the parser may be required to change. When
no adjectives are present in a language, a parser may use a look-ahead of only one symbol, since the next occurring symbol
will uniquely determine the current state of the parser. However, the introduction of adjectives changes this. For example,
if two classes are given attributes of the same name, or if an adjective is inherited from a class’s parent class, then the
presence of the adjective in the symbol stream will not be sufficient to determine which class the forthcoming instance will
belong to. For this reason, it is necessary to make the look-ahead of the parser greater than one. More exactly, the look-ahead
must be greater than the number of adjectives on that class that has the most shared adjectives.
Other conflicts are possible when using enumeration-valued attributes as adjectives, such as a name clash between enumeration
labels for two different attributes or a name clash between an enumeration label and the name of a boolean-valued adjective.
See
4.3.7, “Renaming of Model Elements for HUTN languages,? for ways of overcoming
such conflicts.