From: SourceForge.net <no...@so...> - 2007-07-25 15:22:35
|
Bugs item #1760325, was opened at 2007-07-25 09:48 Message generated for change (Comment added) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1760325&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Classes Group: 3.2.0 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Rony G. Flatscher (orexx) Assigned to: Nobody/Anonymous (nobody) Summary: .clz~SUPERCLASSES returning mixin classes at the wrong posit Initial Comment: 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: .SetCollection .Table ============================================== 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: .InputStream .OutputStream .Object ---------------------------------------------------------------------- >Comment By: Rick McGuire (bigrixx) Date: 2007-07-25 11:22 Message: Logged In: YES user_id=1125291 Originator: NO It is definitely not a). It is really not b) either, but is closer to .Set->Table->SetCollection->MapCollection->Collection->Object 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. ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2007-07-25 11:11 Message: Logged In: YES user_id=662126 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 or ??? 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?? ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2007-07-25 10:09 Message: Logged In: YES user_id=1125291 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 superclasses. This is the correct inheritance order. This is NOT going to be redone just for this situation. ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2007-07-25 10:05 Message: Logged In: YES user_id=662126 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: Set->SetCollection->Table->MapCollection->Object In the case of the InputOutputStream the method resolution should be: InputOutputStream->InputStream->OutputStream->Object [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.] ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2007-07-25 09:53 Message: Logged In: YES user_id=1125291 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1760325&group_id=119701 |