No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Precedence Order
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 07 Sep 2006 18:24:35 +0200
Scott Gargash schrieb:
> 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).
well, that are your requirements, but for others it might be different.
Another question is, whether one would like to have the mixin added in
for a certain class tree, or for each class tree. Using the multiple
superclass approach
allows/forces one to be specific (first case). it is however possible,
to add
on the xotcl level the superclass to the precedence order of all
subclasses of the Base.
Isn't this an option for you?
>
> 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.
as you said, if you want finer control, move more behavior into
[inst]mixins.
everything done with superclasses can be done with mixins alone as well,
since
the class structure is linearized anyhow. However, this leads to a unusual
programming style.
>
> 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?
One can argue in different directions. If one says, the class tree is
the behavior,
you do not want to know, in which class(es) exactly the methods are defined,
but you want to decorate the behavior, the current mixin approach is
appropriate.
Do you have a technical reason, why you want the instmixin BaseMixin in the
precedence order between Base and Derived? I have developed many
applications with mixins/instmixin, and i never had this need.
-gustaf
Date: Thu, 07 Sep 2006 18:24:35 +0200
Scott Gargash schrieb:
> 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).
well, that are your requirements, but for others it might be different.
Another question is, whether one would like to have the mixin added in
for a certain class tree, or for each class tree. Using the multiple
superclass approach
allows/forces one to be specific (first case). it is however possible,
to add
on the xotcl level the superclass to the precedence order of all
subclasses of the Base.
Isn't this an option for you?
>
> 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.
as you said, if you want finer control, move more behavior into
[inst]mixins.
everything done with superclasses can be done with mixins alone as well,
since
the class structure is linearized anyhow. However, this leads to a unusual
programming style.
>
> 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?
One can argue in different directions. If one says, the class tree is
the behavior,
you do not want to know, in which class(es) exactly the methods are defined,
but you want to decorate the behavior, the current mixin approach is
appropriate.
Do you have a technical reason, why you want the instmixin BaseMixin in the
precedence order between Base and Derived? I have developed many
applications with mixins/instmixin, and i never had this need.
-gustaf