"The class that it is mixed in to..."

[John Carter]

Ok, so I'm documenting a Mixin.

Can anyone think of a more sane word / phrase than "The class that it is
mixed in to"?

eg. Array is the class that Enumerable is mixed in to.

In particular has anyone devised a standard way of documenting / enforcing
the signature that "the class that it is mixed in to" must conform to.

To mix in Enumerable it must have a "each" method that accepts a block.

Perhaps one can devise some code in the module that get's activated
at "include" time that checks the instance methods of the class for the required
signature.



John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : (e-mail address removed)
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

 

[Ara.T.Howard]

Ok, so I'm documenting a Mixin.

Can anyone think of a more sane word / phrase than "The class that it is
mixed in to"?

clearly the 'mixer'. tonic for example.

;-)

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[William Morgan]

Excerpts from John Carter's mail of 22 Sep 2005 (CDT):

Ok, so I'm documenting a Mixin.

Can anyone think of a more sane word / phrase than "The class that it
is mixed in to"?
Mixee.

In particular has anyone devised a standard way of documenting /
enforcing the signature that "the class that it is mixed in to" must
conform to.

I suspect most people treat this as falling under the duck typing
principle: just call the method, and if the object doesn't respond, an
error will be raised.

You could call #respond_to? from within append_features, and that would
work for very simple cases. But all you'd be doing is moving a run-time
exception to an earlier part of the program execution. Really, your
best bet is to a) document your module well then b) ignore the problem.

 

[Florian Groß]

Can anyone think of a more sane word / phrase than "The class that it is
mixed in to"?

eg. Array is the class that Enumerable is mixed in to.

In particular has anyone devised a standard way of documenting /
enforcing the signature that "the class that it is mixed in to" must
conform to.

I have no fancy name for the inclusion target, but I have implemented
stating interface requirements via contracts and automatically mixing in
modules when a class fulfills a contract.

It is available on http://ruby-contract.rubyforge.org/ -- it's an
exploratory project which means you probably don't want it as a
dependency right now -- but it also means I'm very curious about
feedback and that it might help others to see new approaches to old
problems.

 

[David A. Black]

Hi --

Excerpts from John Carter's mail of 22 Sep 2005 (CDT):

Mixee.

That would be the module itself -- the thing getting mixed [in]


David

 

[Robert Klemme]

Hi --

Excerpts from John Carter's mail of 22 Sep 2005 (CDT):

Mixee.

That would be the module itself -- the thing getting mixed [in]

This mixup is probably a result of mixing confusion with uncertainty... ;-)

As an alternative - how about TCTIIMIT? I mean pop stars do it and Ruby is
hip, too...

Ok, I'll shut up now.

robert

 

[David A. Black]

Hi --

Ok, so I'm documenting a Mixin.

Can anyone think of a more sane word / phrase than "The class that it is
mixed in to"?

eg. Array is the class that Enumerable is mixed in to.

Array mixes in Enumerable. Array is that class that mixes in
Enumerable. Array is the mixer in of Enumerable....

In particular has anyone devised a standard way of documenting / enforcing
the signature that "the class that it is mixed in to" must conform to.

To mix in Enumerable it must have a "each" method that accepts a block.

Perhaps one can devise some code in the module that get's activated at
"include" time that checks the instance methods of the class for the required
signature.

module Enumerable
def self.included(c)
raise RuntimeError, "#{c} has no 'each'" unless
c.instance_methods.include?("each")
end
end

However... this does too much. Having #each is not a requirement of
including Enumerable. All you're doing when you include Enumerable is
putting some methods on the method search path. Those methods happen
to make calls to #each -- but there's nothing wrong with having a
method that makes a call to #each on your search path, unless you have
no #each and you actually call that method.


David

 

[Randy Kramer]

Excerpts from John Carter's mail of 22 Sep 2005 (CDT):

Mixee.

That would be the module itself -- the thing getting mixed [in]

I guess when I hear "mixee" I expect a "mixer" to exist. So one would be the
mixer and one would be the mixee.

My first thought is that I would call the thing getting mixed in the mixer and
the other (the thing getting something mixed into it) the mixee.

? ;-)

Randy Kramer

 

[William Morgan]

Excerpts from Randy Kramer's mail of 23 Sep 2005 (CDT):

My first thought is that I would call the thing getting mixed in the
mixer and the other (the thing getting something mixed into it) the
mixee.

My thought pattern exactly. Unfortunately "mixin" is the official name
of the "mixer", so "mixee" does sound a bit odd. Oh well, it's
English---we don't value linguistic consistency in the first place.

Other options are target, recipient, subject... victim?

 

[Randy Kramer]

My thought pattern exactly. Unfortunately "mixin" is the official name
of the "mixer", so "mixee" does sound a bit odd. Oh well, it's
English---we don't value linguistic consistency in the first place.

Other options are target, recipient, subject... victim?

For me (not the OP), one of those sounds better, less opportunity for
confusion, imho.

Maybe of those, target would be good, and it might often be preceded by
"mixin", e.g., I might refer to the "mixin" and the "mixin target".

Hmm, actually, mixin doesn't sound quite right for the first case (the thing
being mixed in), but I don't have a better suggestion ATM.

Randy Kramer

 

[Logan Capaldo]

--Apple-Mail-1-1018709128
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

My thought pattern exactly. Unfortunately "mixin" is the official name
of the "mixer", so "mixee" does sound a bit odd. Oh well, it's
English---we don't value linguistic consistency in the first place.

Other options are target, recipient, subject... victim?

What about "mixture"? Although that kind of implies the class +
mixin, not just the class. Maybe solvent? (I'm going way out there
with these mix metaphors)
--Apple-Mail-1-1018709128--

 

[Nicholas Seckar]

module Enumerable
def self.included(c)
raise RuntimeError, "#{c} has no 'each'" unless
c.instance_methods.include?("each")
end
end

However... this does too much... [snip]

In addition,

class A
include Enumerable
def each
yield 1
yield 2
end
end
RuntimeError: A has no each!!!
from (irb):2:in `included'
from (irb):5:in `include'
from (irb):5
from :0

 

[Sean O'Halpin]

Where does the term 'mixin' come from?

Don't we 'include' or 'extend' modules?

So shouldn't the class (or module) that includes or extends a module
be called the 'includer' or 'extender'?

Just my tuppence worth.

Regards,

Sean

 

[Randy Kramer]

What about "mixture"? Although that kind of implies the class +
mixin, not just the class. Maybe solvent? (I'm going way out there
with these mix metaphors)

(Again, I'm not the OP, but) mixin/mixture has some promise.

Randy Kramer

 

[Randy Kramer]

So shouldn't the class (or module) that includes or extends a module
be called the 'includer' or 'extender'?

Extender sounds good to me, except that:

* the mixin terminology is pretty well established. Still, if a
terminology change is appropriate, the sooner the better.
* what do we use then, extender and extendee? Not much better than mixer
and mixee, imho

Don't know why I keep sticking my nose in here--will try to restrain
myself ;-)

Randy Kramer

 

[Ben]

Extender sounds good to me, except that:

I'm new, so maybe this is a terrible idea, or maybe it has been
mentioned. How about the "implementor"?
I guess it has the potential to be confused with inheritance, but if
we didn't like ambiguity, we'd use static typing!

-Ben

 

[David A. Black]

Hi --

Excerpts from John Carter's mail of 22 Sep 2005 (CDT):
Can anyone think of a more sane word / phrase than "The class that it
is mixed in to"?

Mixee.

That would be the module itself -- the thing getting mixed [in]

I guess when I hear "mixee" I expect a "mixer" to exist. So one would be the
mixer and one would be the mixee.

My first thought is that I would call the thing getting mixed in the mixer and
the other (the thing getting something mixed into it) the mixee.

I see it as analgous to:

Employer employs employee.
Nominator nominates nominee.

thus:

Mixer mixes in mixee.

Of course, it's not really mixer or mixee -- more like mixer in and
mixinee

In practice, 'ee' usage is actually sort of weird and inconsistent.
"Attendee" (person who attends) and "standee" (person who stands) come
to mind as "backwards" examples.


David

 

[Sean O'Halpin]

My point was that Ruby has two ways of 'mixing in' a module -
inclusion and extension. We already have words that exactly describe
the relationship between the including/extending class/module and the
included/extended module.

Why invent an ambiguous alternative?

Sean

P.S. Hi David - when are you back in London?

 

[John Carter]

clearly the 'mixer'. tonic for example.

I like that. Cocktail. Included, not stirred, nor shaken. (Sorry, I was
just reading Larrry Wall's rather bewildering State of the Onion address
with it's Spy theme, hence the James Bond cultural reference.)

Hmm. David's proposal and Nicolas's counter example got me thinking.

For example, the required methods, eg. "each" need not be provided by the
cocktail, but possibly by another mixin included into the cocktail.

However, it is something that could be checked by the invariant of the
class. In fact, it's not a class invariant but a Class.invariant... if you
get my meaning. In fact you could get away with checking it once at the
start of the constructor.



John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : (e-mail address removed)
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

 

[Devin Mullins]

Hmm. David's proposal and Nicolas's counter example got me thinking.

For example, the required methods, eg. "each" need not be provided by=20
the cocktail, but possibly by another mixin included into the cocktail.

However, it is something that could be checked by the invariant of the=20
class. In fact, it's not a class invariant but a Class.invariant... if=20
you get my meaning. In fact you could get away with checking it once=20
at the start of the constructor.

That seems very anti-duck. I see no reason why an Object's meaning could=20
not change over the life of the object -- at one point Enumerable and at=20
another point not. Also, thanks =E0 method_missing, an object need not=20
declare that it responds to #each.

Devin