Attribute concepts

Attributes are named arbitrary data

The attribute mechanism provides a way to attach named characteristics or properties to other data. These characteristics can themselves be any type of data. For example, you can attach the font size "24" to a range of text data as an attribute of that data. The attribute name would be font size and the data it names would be the value 24.

Consider categories of names to be an optional extension of the name itself. Unless otherwise noted, assume that name refers to both an attribute's name and its category. See "Reducing attribute access time using categories" on page 164 for more information.

Figure 38 illustrates how attributes name arbitrary data. The names do not have any specific function other than providing a means to access the wrapped data.

The name can be specific to the instance, shared by all instances of a class, or shared among instances of several related classes. The wrapping itself is performed when an attribute is instantiated, and is a completely dynamic operation. All attribute creation and deletion is performed at runtime.

NOTE While an attribute of a given class does not necessarily have a given name, attributes of a given name must always be of a given class.

The data portion of an attribute is completely arbitrary. There is no protocol in any of the attribute classes that deal with attribute data. The assumption is that if you know enough to ask for a particular attribute, then you know the class of that attribute and the form of its data. Derived classes usually add their own protocol to access the wrapped data.

Attributes can be grouped

Typically, you use groups of attributes to describe data. For example, both the font name and the font size are attributes that describe a range of text. You use attribute groups to handle multiple attributes associated with a single data element. Figure 39 shows two examples of attribute groups.

Within a group, no two attributes have the same name. Thus groups may be thought of as sets of named values.

To access an attribute in a group, you query the group by passing an attribute that has the desired name. If the group contains an attribute with that name, that attribute is returned. Then you can coerce the returned attribute to the proper class; this is because an attribute of a given name always has a given class. Finally, you call member functions specific to that class to access the attribute's data.

Attributes are immutable, groups are no t

Once created, attributes are immutable; that is, they cannot be changed. However, you can change attribute groups by adding and removing attributes or by changing their inheritance hierarchy. Figure 40 shows how an attribute group is updated given that attributes are immutable. In this example, the existing attribute group contains a size attribute of 12. To change the size to 14, you create a new size attribute and add it to the group, effectively discarding the old size attribute of 12.

Attributes can share data

Attributes can share attribute data. This lets you store the data once and create and copy attributes with relatively low overhead. The instance that holds the data is called an internal attribute, and the attributes that share this data are called shared attributes. All access to the internal attribute is through the shared attribute; the internal attribute is not otherwise accessible. You accomplish sharing by having the shared attributes point to one internal attribute, as shown in figure 41.

Internal attributes are managed by a special class that do not need to be accessed directly. This class ensures that there is only a single internal attribute with a given name and value.

You can share groups

If you want to store a group of attributes once, yet refer to it from different places in your code, you can share the attribute group as well. The group that owns the attributes is called an internal group, and the groups that point to this group are called group handles. You can have many group handles pointing to the same internal group, as shown in figure 42.

Attributes and groups have value semantics, GroupHandles have reference semantics

Because attributes are immutable, even shared attributes have value semantics. Each instance of a shared attribute behaves as though it is unique. Simple groups own their attributes and therefore also have value semantics. Modifications to a group do not affect other groups.

GroupHandles, as the name implies, explicitly share their underlying groups and therefore have pointer semantics. When you copy and modify a GroupHandle, other GroupHandles might be affected because change information is propagated to handles.

Group attributes may be dynamically inherited from other groups

You can organize groups in a hierarchy, providing for dynamic inheritance of attributes from parent groups. In the CommonPoint application system, this is provided by inherited internal groups and inherited group handles. This feature allows you to query a group for an attribute, and if it is not found automatically, query its parent group, and so on recursively until the attribute is found or it is determined that a group has no parent.

Child groups can override inherited attributes simply by adding an attribute with the same name. The parent of a group can change at any time.

Group changes provide notification

Because internal attribute groups can be changed, the attributes subsystem provides a notification service to inform the group's handles whenever a change occurs. This is not necessary for shared attributes because, by definition, attributes do not change. The attributes notification service informs handles not only of changes to a single internal attribute group, but of changes to its ancestor groups, as well as of changes to the group hierarchy itself.

NOTE The attributes subsystem notification facility is a unique and custom service and is not related to the Notification framework.

Figure 43 shows the relationship between group handles that can be inherited, internal attribute groups that can be inherited, and their parent internal groups. Any change to a group that can be inherited notifies both its handles and the handles of the groups below it. Therefore, in Figure 43 any change to Group C notifies handles for both C and D, and any change to Group B notifies handles to B, C, and D.

[Contents] [Previous] [Next]

Click the icon to mail questions or corrections about this material to Taligent personnel.

Generated with WebMaker