Re: very simple per-object mixins

When people say "mxin" around Perl, they usually seem to be talking about things that magically add methods to an existing package. That always sounded like a really bad idea to me: "action at a distance" in a big way.

What you're doing -- changing inheritance at runtime -- seems different to me. Still scary, but not as scary as mxins. One other approach would be to use something like a "strategy pattern." If that seems too heavy, it could be made more lightweight by using sub references in place of actual objects to implement the hooks.

Comment on Re: very simple per-object mixins

Replies are listed 'Best First'.
Re: Re: very simple per-object mixins by tilly (Archbishop) on Nov 05, 2003 at 21:22 UTC
This is an odd phenomena. 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.	[reply]

Replies are listed 'Best First'.

Re: Re: very simple per-object mixins
by tilly (Archbishop) on Nov 05, 2003 at 21:22 UTC

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.

[reply]