In the documentation on Class Precedence, it clearly states that Class Attributes are not inherited:
- Subclasses do not inherit a superclass InferiorClasses attribute. Only classes specified in the subclass InferiorClasses attribute are inferior to subclass objects.
However, what I can't seem to find is any comment on whether the specified InferiorClasses should also cause objects of classes that are subclasses of the InferiorClasses to be non-dominant arguments to functions/methods. I would argue that this is desirable under certain circumstances, but it does not seem to be the case.
For example:
I am creating a Collection class that redefines brace indexing to allow dictionary lookups into an array of "collected" objects based on values of specific properties of the class. (e.g. an "ID" property). Parenthesis and dot indexing are also being redefined to forward those indexing operations to the underlying array of objects as well. This is meant to be general functionality, and so I would like to make it such that any class that is eligible to be wrapped by the Collection class should inherit from an abstract Collectable mixin class that requires the inheriting class to define a couple metadata properties. Ideally, the Collection class should support operations with combinations of Collections and arrays of an underlying Collectable class, specifically for things like concatenation and set operations (union, intersect, setdiff). Because of this, I want the Collection version of a method (e.g. cat) to be dominant so that it is invoked even if it isn't the leftmost argument to the method. However, specifying (InferiorClasses = {?Collectable}) as an attribute of Collection does not appear to effect the desired behavior. This is further complicated by the fact that a Collectable class could also be a heterogeneous root class, and therefore attempting to explicitly enumerate all possible inferior classes is not really practical and also makes it more difficult to reuse the functionality in the future.
