Re: Real (trivial) mixins

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: