<br><font size=2><tt>Gustaf Neumann <neumann@wu-wien.ac.at> wrote
on 09/04/2006 03:50:42 AM:<br>
<br>
> Scott,<br>
> <br>
> you can achieve the precedence you are wanting by adding multiple
<br>
> superclasses to Derived.<br>
> In the forthcoming version (which will be named 1.5), you can even
use <br>
> "superclass add" like<br>
> in the following example.<br>
</tt></font>
<br><font size=2><tt>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).</tt></font>
<br>
<br><font size=2><tt>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.</tt></font>
<br>
<br><font size=2><tt>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.</tt></font>
<br>
<br><font size=2><tt>What's the scenario where it's desireable for BaseMixin
to be ahead of Derived?</tt></font>
<br>