#367 .clz~SUPERCLASSES returning mixin classes at the wrong posit

Classes (182)

While testing the refactored collection class methods with the test units, errors occur.

Going after possible causes I found that mixed in classes seem to not be listed in the correct position in the array that gets returned:

E.g. .set's superclass order (from a rexxtry session):

-------- cut here -------
do cl over .set~superclasses;say cl;end
The Table class
The SetCollection class
-------- cut here -------

Hence the PUT-method of .Table is found and resolved before the PUT-method of .SetCollection.

The superclass list should show the mixed in classes (in inherited order) first, hence:



Another exmaple ('InputOutputStream'):

-------- cut here -------
do cl over .inputOutputStream~superclasses;say cl;end
The Object class
The InputStream class
The OutputStream class
-------- cut here -------

should list the superclasses in the following order:



  • Rick McGuire

    Rick McGuire - 2007-07-25

    Logged In: YES
    Originator: NO

    The superclasses method explicitly defines that the immediate superclass is the first item in the superclasses array. All inherited classes are placed after that, in the order in which they are inherited.

  • Rony G. Flatscher

    Logged In: YES
    Originator: YES

    Since when??

    There is no logic in this sequence, if the superclasses array is used for resolving methods by inheritance.

    In the case of the Set class the method resolution should be:


    In the case of the InputOutputStream the method resolution should be:


    [Because of this I have been feeling a little bit uneasy about your addition of the new method named SUPERCLASS not returning the immediate superclass from which methods get inherited next; but there was no time to discuss that as you had implemented and committed it already.]

  • Rick McGuire

    Rick McGuire - 2007-07-25

    Logged In: YES
    Originator: NO

    Since always. Here's the documentation for superclasses from the class class.

    Returns the immediate superclasses of the receiver class in the form of a single-index array of the
    required size. The immediate superclasses are the original class used on a SUBCLASS or a
    MIXINCLASS method, plus any additional superclasses defined with the INHERIT method. The array is
    in the order in which the class has inherited the classes. The original class used on a SUBCLASS or
    MIXINCLASS method is the first item of the array. The array indexes range from 1 to the number of

    This is the correct inheritance order. This is NOT going to be redone just for this situation.

  • Rony G. Flatscher

    Logged In: YES
    Originator: YES

    Hmm, you are right w.r.t. documentation (looked up the OS/2 documentation of Object REXX from July 7, 1995)!

    But then, what is the inheritance path for .Set?

    Is it

    a) .Set->SetCollection->Table->MapCollection->Collection->Object?

    or is it

    b) .Set->Table->Object->SetCollection->MapCollection->Collection->Object



    If it is not a), then what is the purpose of a mixin-class (how does it change the lookup of inherited methods)? Why would one state on .Set that it inherits .SetCollection, if that is honored after looking up .Table??

  • Rick McGuire

    Rick McGuire - 2007-07-25

    Logged In: YES
    Originator: NO

    It is definitely not a). It is really not b) either, but is closer to


    But even that is not strictly accurate, as the relationship is not strictly linear with regard to what method would get invoked when a super override is used.

    With the added methods sitting between the superclass and the common base class.

    Mixin classes are not intended to method overrides, they are intended for adding in additional behavior, and also work quite nicely for tagging purposes to establish isA relationships. That was the original purpose of those classes, but someone insisted that these needed to be refactored with concrete method implementations. In order for Set and Bag to work correctly, these classes will need to implement their own overrides of the table class method.

  • Rony G. Flatscher

    Logged In: YES
    Originator: YES

    Hmm. Of course I cannot speak for (or know of) the original ideas/concepts that were associated with allowing multiple inheritance to become part of Object REXX more than 12 years ago.

    However, multiple inheritance, mixins etc. are rather well established concepts in the OO world. There are different takes e.g. what the semantics of a "mixin" would/should be.

    The ooRexx name "INHERIT" in the class directive (or the the method's name "INHERIT" in "Class") indicate that methods/behaviour from other classes are "mixed-in" influencing the inheritance of methods. Those classes in ooRexx must be defined with the keyword "MIXINCLASS" instead of "SUBCLASS" and have the same baseclass as the class that inherits the methods of these classes.

    The ooRexx documentation on the CLASS directive (p. 118) states:

    "If you specify the MIXINCLASS option, the class becomes a subclass of the class mclass for inheritance of instance and class methods. You can add the new class instance and class methods to existing classes by using the INHERIT option on a ::CLASS directive or by sending an INHERIT message to an existing class. If you specify neither the SUBCLASS nor the MIXINCLASS option, the class becomes a non-mixin subclass of the Object class.

    If you specify the INHERIT option, the class inherits instance methods and class methods from the classes iclasses in their order of appearance (leftmost first). This is equivalent to sending a series of INHERIT messages to the class object, with each INHERIT message (except the first) specifying the preceding class in iclasses as the classpos argument. (See INHERIT .) As with the INHERIT message, each of the classes in iclasses must be a mixin class. The iclasses is a blank-separated list of literal strings or symbols that are taken as constants. If you omit the INHERIT option, the class inherits only from sclass."

    So it seems clear that these concepts have to do with the inheritance of methods, in this case by mixin them into an existing inheritance tree. (Or with other words: the concept is aimed at supplying/mixin additional methods/behaviour to a class.)

    In general, to "mixin" another class always means that the inheritance/lookup path for methods is changed for the particular class that is used for inheriting the mixin classes.

    The only thing (I thought) that could be discussed, is how the mixins take effect: should the mixed-in classes be looked up before the object resp. the class the object stems from (as in OTcl and XOTcl) or after the object resp. class the object stems from, but before the direct superclass (such that classes are "mixed-in" between the class and its direct superclass).

    E.g. there is a scientific paper on the XOTcl mixin concepts (extending MIT's OTcl), "Object-based and class-based composition of transitive mixins" at http://wi.wu-wien.ac.at/home/mark/publications/ist-v49n8-aug07.pdf.

    This paper is also interesting for its list of related mixin/multiple-inheritance references/papers that it is has used to develop and discuss the concepts of XOTcl.

    In any case, I think, there is a need to unambiguously and clearly define what it means in ooRexx, if someone declares a particular class to inherit mixin classes. (It should be simple, clear and understandable how multiple inheritance in ooRexx affects the method

  • Rony G. Flatscher

    Logged In: YES
    Originator: YES

    Just another observation:

    It is definitely not a). It is really not b) either, but is closer to


    This would define that .Table was a subclass of .SetCollection, inheriting the .SetCollection methods. Hence a table object would be of type .SetCollection, which is not correct. [The mixin .SetCollection must not be a superclass of .Table.]

    These would be "is a" assertions that should hold (the only thing important would be that all listed classes are superclasses of the object for which "is a" is asserted):

    • a set object is a Collection, a MapCollection, a SetCollection, a Table, an Object
    • a table object is a Collection, a MapCollection, an Object
    • a SetCollection object is a Collection, an Object
    • a MapCollection object is a Collection, an Object
    • a Collection object is an Object

    Now looking at .Set these are all the partial inheritance trees that need to be set up for it:

    • .Set -> .Table (subclassed by .Set) -> .Object (subclassed by .Table)

    • .SetCollection (inherited by .Set) -> .Collection (subclassed by .SetCollection)-> .Object (subclassed by .Collection)

    • .MapCollection (inherited by .Table) -> .Collection (subclassed by .MapCollection) -> .Object (subclassed by .Collection)

    Therefore the six classes .Set, .Table, .Object, .SetCollection, .Collection, and .MapCollection need to be ordered such that for .Set instances each class is searched for methods exactly once.

    If I am not mistaken there are two general possibilities in this case to set up the inheritance tree for .Set, going from .Set to the root class .Object, baseclass for all is .Object:

    1) Mixin-classes are "injected" after the inheriting class and before its single-inheritance superclass:

    .Set->.SetCollection-> .Table->.MapCollection->.Collection-> .Object

    2) Mixin-classes are "injected" before the inheriting class (à la OTcl/XOTcl):

    .SetCollection->.Set-> .MapCollection->.Collection->.Table-> .Object



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks