I agree with you that when I sit down and describe what mixins do, I think that they have to be bad. Bad for the same reason that it is better to use @EXPORT_OK than @EXPORT.
However when I actually saw them and played with them in Ruby, they were very nice, integrated very well, and the examples that I saw were a joy to play with.
After some thought, I think that my closing thoughts at Pass by reference vs globals applies. In Ruby when people use mixins, they usually are mixing in a handful of base modules like Enumerable. Because these modules are mixed in everywhere - including in every part of the Ruby library where they make sense - they become something that you just reach for and always find. The cost of learning the interface is paid for because you get the benefit of using it everywhere in Ruby. And what is added really is useful, lots of utility methods that you would have written yourself time after time again. Methods that you can depend on to always be there, under the name that you expect.
Therefore my current (and highly provisional) opinion is that mixins are a bad idea unless you do them a lot. If you do them pervasively in a very predictable way, then they can become a good thing because the effort of learning the interface and potential conflicts are amortized over a lot of benefit of relying on the benefits to be there.
A consequence of that opinion is that in languages (like Perl) where people don't use mixins pervasively, attempting to introduce them is a bad idea because you won't get to the point where the cost/benefit ratio is in your favour.
In reply to Re: Re: very simple per-object mixins
by tilly
in thread very simple per-object mixins
by khkramer
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |