|
« Return to Thread: Real (trivial) mixins
Re: Real (trivial) mixins
by Jeremy Tregunna-2
::
Rate this Message:
What you're describing is an aspect. Note I didn't provide an
asAspect, because that would make absolutely no sense in the context
of the one liner i posted initially. Aspects definitely need to be
updated if something changes, mixins do not usually. In the case where
they may need to be, just continue as normal, no need to use the
asMixin method I provided. To me, I look at mixins that mix in
behaviour to a specific case, unlikely to have interdependencies to
other mixins. If the latter is the case, then I think of them as
aspects, and flip my brain to AOP style. But who knows, maybe that's
just me.
On 15-Apr-09, at 2:07 PM, Nick Guenther wrote:
> I think you're getting caught up in this detail of Io's behaviour.
> Mixins are very useful for collecting a set of behaviour in one
> package *that can be attached to types at will*. A favourite use of
> mine is to quickly turn things into -like types (e.g. list-like or
> dictionary-like types); in, say, Java you're stuck with rewriting all
> the functionality yourself (even if you state that your type
> "implements" a particular interface), while in python I can write a
> mixin that provides sorting if you'll just define get(index) and
> set(index) methods.
>
> For a real world example: I just wrote a couple python mixins that
> provide "name" and "description" functionality for classes in the
> textadventure I'm writing. Respectively they pull out the class's name
> and replace the underscores with spaces and titlecase the names, and
> pull a default item description from the docstring but allow you to
> override it (okay so maybe this last use is a bit contrived but I
> didn't want to tie myself to docstrings unneccessarily). The typical
> single-inheritence solution would be to make everything with
> descriptions and names inherheit from one superclass, which usually
> works for a while but webs you in more and more as the program gets
> built.
>
> If I changed the mixin I definitely would want everything that pulled
> from it to get the change since the mixin behaviour belongs to the
> mixin, it's just letting other things borrow. I must confess I've
> never actually thought of trying to do this, though. What a curious
> idea!
>
> -Nick
>
> On 15/04/2009, spir <denis.spir@...> wrote:
>> Le Wed, 15 Apr 2009 10:04:38 -0700,
>> "Samuel A. Falvo II" <sam.falvo@...> s'exprima ainsi:
>>
>>>> Hmm.. can you explain a bit more -- *why* you would want to do
>>>> this.
>>>
>>> Isolation. Use this method when/if you anticipate your parent(s)
>>> might change in the future, but you want to preserve their current
>>> behavior as a snapshot now.
>>
>> I would rather ask the opposite question: in which (real world and/or
>> theoretical) case can one expect the parent methods to change *and*
>> wish
>> this change to propagate to clones?
>>
>> Denis
>> ------
>> la vita e estrany
>>
Regards,
Jeremy Tregunna
jeremy.tregunna@...
asAspect, because that would make absolutely no sense in the context
of the one liner i posted initially. Aspects definitely need to be
updated if something changes, mixins do not usually. In the case where
they may need to be, just continue as normal, no need to use the
asMixin method I provided. To me, I look at mixins that mix in
behaviour to a specific case, unlikely to have interdependencies to
other mixins. If the latter is the case, then I think of them as
aspects, and flip my brain to AOP style. But who knows, maybe that's
just me.
On 15-Apr-09, at 2:07 PM, Nick Guenther wrote:
> I think you're getting caught up in this detail of Io's behaviour.
> Mixins are very useful for collecting a set of behaviour in one
> package *that can be attached to types at will*. A favourite use of
> mine is to quickly turn things into -like types (e.g. list-like or
> dictionary-like types); in, say, Java you're stuck with rewriting all
> the functionality yourself (even if you state that your type
> "implements" a particular interface), while in python I can write a
> mixin that provides sorting if you'll just define get(index) and
> set(index) methods.
>
> For a real world example: I just wrote a couple python mixins that
> provide "name" and "description" functionality for classes in the
> textadventure I'm writing. Respectively they pull out the class's name
> and replace the underscores with spaces and titlecase the names, and
> pull a default item description from the docstring but allow you to
> override it (okay so maybe this last use is a bit contrived but I
> didn't want to tie myself to docstrings unneccessarily). The typical
> single-inheritence solution would be to make everything with
> descriptions and names inherheit from one superclass, which usually
> works for a while but webs you in more and more as the program gets
> built.
>
> If I changed the mixin I definitely would want everything that pulled
> from it to get the change since the mixin behaviour belongs to the
> mixin, it's just letting other things borrow. I must confess I've
> never actually thought of trying to do this, though. What a curious
> idea!
>
> -Nick
>
> On 15/04/2009, spir <denis.spir@...> wrote:
>> Le Wed, 15 Apr 2009 10:04:38 -0700,
>> "Samuel A. Falvo II" <sam.falvo@...> s'exprima ainsi:
>>
>>>> Hmm.. can you explain a bit more -- *why* you would want to do
>>>> this.
>>>
>>> Isolation. Use this method when/if you anticipate your parent(s)
>>> might change in the future, but you want to preserve their current
>>> behavior as a snapshot now.
>>
>> I would rather ask the opposite question: in which (real world and/or
>> theoretical) case can one expect the parent methods to change *and*
>> wish
>> this change to propagate to clones?
>>
>> Denis
>> ------
>> la vita e estrany
>>
Regards,
Jeremy Tregunna
jeremy.tregunna@...
« Return to Thread: Real (trivial) mixins
| Free embeddable forum powered by Nabble | Forum Help |
