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 : john.carter@tait.co.nz
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.
Can anyone think of a more sane word / phrase than "The class that it is mixed in to"?
--
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
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.
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.
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.
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
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 : john.carter@tait.co.nz
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.
···
On Fri, 23 Sep 2005, Ara.T.Howard wrote:
On Fri, 23 Sep 2005, John Carter wrote:
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"?
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
···
On Friday 23 September 2005 08:58 am, David A. Black wrote:
On Fri, 23 Sep 2005, William Morgan wrote:
> 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]
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.
That seems very anti-duck. I see no reason why an Object's meaning could not change over the life of the object -- at one point Enumerable and at another point not. Also, thanks à method_missing, an object need not declare that it responds to #each.
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?
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
···
On Sat, 24 Sep 2005, Randy Kramer wrote:
On Friday 23 September 2005 08:58 am, David A. Black wrote:
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
···
On Friday 23 September 2005 11:30 am, William Morgan wrote:
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)
···
On Sep 23, 2005, at 11:30 AM, William Morgan wrote:
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?
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.
(Again, I'm not the OP, but) mixin/mixture has some promise.
Randy Kramer
···
On Friday 23 September 2005 03:04 pm, Logan Capaldo wrote:
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)
* 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
···
On Friday 23 September 2005 04:04 pm, Sean O'Halpin wrote:
So shouldn't the class (or module) that includes or extends a module
be called the 'includer' or 'extender'?
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
···
On 9/23/05, Randy Kramer <rhkramer@gmail.com> wrote:
