No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Precedence Order
From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 5 Sep 2006 08:43:30 -0700
Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 09/04/2006 03:50:42 AM:
> Scott,
>
> you can achieve the precedence you are wanting by adding multiple
> superclasses to Derived.
> In the forthcoming version (which will be named 1.5), you can even use
> "superclass add" like
> in the following example.
Thanks, but in my particular case I don't have knowledge of Derived, only
Base. By that, I mean I'm actually adding BaseMixin (the HW simulator) to
Base (the HW) before Derived has even been created. I'd like for Derived
to remain ignorant of BaseMixin because BaseMixin only exists for testing
purposes. I prefer to avoid having code paths that exist only for testing
purposes. (Which mixins are particualrly well-suited for).
My current solution is to make Derived a mixin as well. This then forces
it to the head of the precedence order regardless of the existence of
BaseMixin so I don't have different code paths for BaseMixin vs. Base. It
works, but it's not really correct from a design standpoint. Derived
should be a derived class (it's a unique type), not a mixin.
This is what I meant about the current precedence order breaking
encapsulation. I wish to modify a single class, but the precedence order
makes it be global. In order to get things to work, I have to distribute
knowledge of BaseMixin to places in the hierarchy that (I believe)
shouldn't have to know or care.
What's the scenario where it's desireable for BaseMixin to be ahead of
Derived?
Date: Tue, 5 Sep 2006 08:43:30 -0700
Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 09/04/2006 03:50:42 AM:
> Scott,
>
> you can achieve the precedence you are wanting by adding multiple
> superclasses to Derived.
> In the forthcoming version (which will be named 1.5), you can even use
> "superclass add" like
> in the following example.
Thanks, but in my particular case I don't have knowledge of Derived, only
Base. By that, I mean I'm actually adding BaseMixin (the HW simulator) to
Base (the HW) before Derived has even been created. I'd like for Derived
to remain ignorant of BaseMixin because BaseMixin only exists for testing
purposes. I prefer to avoid having code paths that exist only for testing
purposes. (Which mixins are particualrly well-suited for).
My current solution is to make Derived a mixin as well. This then forces
it to the head of the precedence order regardless of the existence of
BaseMixin so I don't have different code paths for BaseMixin vs. Base. It
works, but it's not really correct from a design standpoint. Derived
should be a derived class (it's a unique type), not a mixin.
This is what I meant about the current precedence order breaking
encapsulation. I wish to modify a single class, but the precedence order
makes it be global. In order to get things to work, I have to distribute
knowledge of BaseMixin to places in the hierarchy that (I believe)
shouldn't have to know or care.
What's the scenario where it's desireable for BaseMixin to be ahead of
Derived?