Inheritance in Object-Specific Methods

Query, change, notify, and named methods are all object-specific methods. Of these methods, only named methods are values in fields of RODM objects. Query, change, and notify methods are all stored in subfields of objects. On an object, the named method fields and subfields on fields are inherited from the subfields of the public classes of that object.

In the same way, the values in named method fields and the values in query and change subfields can be inherited through primary inheritance, using the standard principles for supporting inheritance in RODM. Notify methods are inherited from the primary parent to its object children. They are not inherited throughout the class inheritance tree. However, the object fields can additionally have local values that do not override the class-level notification subscriptions. (So standard inheritance of values does not apply to notification subfields.)

Named methods, query methods, change methods and notification methods can also all exist on classes. Change methods on classes (as on objects) can be used to validate changes before they are made, or they can be used to validate a user's authority to make those changes. Query methods can validate a requestor's authority to see the requested data, or they can validate data before it is returned. Likewise, named methods on classes can be used in ways similar to the ways such methods are used on objects. Complex changes to a class can be run by a named method, or general-purpose functions, applicable to many individual classes, can be implemented with named methods. Finally, notification methods are also valuable on classes.

Change and notification methods on children that are inheriting values from parents are not triggered when the inherited values are changed on parents. Therefore, notification methods are required on parents (which can be classes) so that user applications can be notified when parameters and values change on parents.

The main purpose of the primary hierarchy of classes is to make it easy to specify the organization of and default values in RODM objects. The most common values that are inherited at the object level from the primary hierarchy include:
  • Methods and parameters to control the management of RODM data to reflect real-world objects
  • Policy parameters that indicate standard limits and thresholds
  • Long-lived characteristics, such as capacity, of RODM objects where those characteristics are needed to manage real-world objects
These methods and values appear in fields on classes so they can be stated once and then inherited by many objects through the primary hierarchy.

When a value that is a method is inherited by a child, if that method is triggered and run for a child, execution takes place in the context of the child. While the method resided on the parent, only its name and its long-lived parameters are picked up through the inheritance process. When such a method runs and asks for the contents of a field, it gets the contents of that field on the child entity.

A query, change, or named method installed on a class can fill two roles. The method can be the default change method inherited by children and applied in the context of those children (including children that are objects instead of classes), and it can be triggered in the standard way (query, change of field, direct invocation) in the context of the parent.

Be aware that object-specific method you write can sometimes run on an object and at other times can run on a class. The same kinds of capabilities are available for both objects and classes, using the same method API calls. Many object-specific methods look at the WhatIAm field on the current entity to discover the context in which the method is executing, and different actions might be appropriate in different contexts.

Query, change, named, and notification methods on fields of classes are triggered as part of transactions against those classes just as those kinds of methods are triggered on objects. Also, query, change, and named methods exist on fields of classes to support inheritance of those methods by objects, but inheritance of values in notification subfields is not supported in RODM.

If a notification list exists through inheritance, it begins as a null value. A null value in the notification list field is functionally equivalent to no list at all. Entries can be added to a notification list by using the EKG_AddNotifySubscription function.

In summary, named methods and query, change, and notify subfields all function in the standard way both on private and on public fields of classes. There is no inheritance involving private fields, but query, change, and notification methods are run when the corresponding field is queried or changed. When a field is on a class (as with fields on objects), a change transaction for the field triggers change and notification methods, but a change transaction for the value subfield of a field does not trigger change and notification methods. This function is the same as that supported for objects.