well, why do you think the behavior breaks encapsulation? Rather a behavior where mixin are not added in precedence before the class hierarchy, requires you to know about the interceptor and might break encapsulation. Consider you are omitting to use "next" in a method of Derived, for instance simply because this method exists nowhere else in the class hierarchy. If the mixin would be introduced after Derived, you would need to modify Derived to introduce a method of the same name on the mixin. If the mixin is always before the class hierarchy, as a base hierarchy developer you don't need to care for how a potential mixin is designed, because you can be sure once a call has reached your class, you can be sure, you cannot accidently introduce side-effects on mixins (maybe designed later by other developers).
Scott Gargash wrote:
As I understand it, precedence order is computed as filters then mixins the superclasses, and this sort order is applied "globally" to an object.
In other words:
Class create Base Class create Derived -superclass Base Derived d d info precedence ==> ::Derived ::Base ::xotcl::Object
Class create BaseMixin Base instmixin add BaseMixin d info precedence ==> ::BaseMixin ::Derived ::Base ::xotcl::Object
This behavior seems to violate encapsulation. BaseMixin is intended to intercept messages to Base. Derived doesn't know about BaseMixin and BaseMixin doesn't know about Derived, yet BaseMixin ends up being the first interceptor of messages to Derived.
Since BaseMixin is intended to modify the behavior of Base, it would be better BaseMixin preceeded Base (and only Base) in the sort order.
d info precedence ==> ::Derived ::BaseMixin ::Base ::xotcl::Object
The current behavior means you can't really add a mixin without understanding everywhere that the object being extended is used. Is there some benefit to the current behavior that I don't understand?
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl