Why the lack of mixing-in support for Class methods?

Ruby
21

On Jun 8, 2006, at 1:23 PM, Alex Y. wrote:

derive (a little obscure)
evolve (I quite like that)

evolve seems vague and makes people think of monkeys

– Elliot T.

22

Alder G. wrote:

On 6/8/06, Austin Z. [email protected] wrote:

…
No, I don’t have a better name. I thought of #blend, but that’s just
too … ugly.

I like #blend. Goes well with #blend? etc.

Some other nice alternatives from the thesaurus: meld, merge, mingle,
fuse, combine, integrate, compound.

A few others:

derive (a little obscure)
evolve (I quite like that)
elaborate (too long?)
develop
gather (gets the dual nature quite nicely)
invoke (seems too active to me)
follow (like evolve, but less so)

This could go on all night :slight_smile:

23

Elliot T. wrote:

evolve seems vague and makes people think of monkeys
Sure. Monkey patching.

–
James B.

“Blanket statements are over-rated”

24

On 6/8/06, Elliot T. [email protected] wrote:

fuse, combine, integrate, compound.
A few others:

derive (a little obscure)
evolve (I quite like that)

evolve seems vague and makes people think of monkeys

What’s wrong with that? :wink:

Ok, now I have to toss some out…

engulf (seems bigger than include or extend)
completes (give me the complete list of methods)
clobber (silly, but it’s likely to do that to some methods, and has
CLass/OBject mnemonic).

25

From: “Bill G.” [email protected]

I like #blend. Goes well with #blend? etc.

Ok, now I have to toss some out…

engulf (seems bigger than include or extend)
completes (give me the complete list of methods)
clobber (silly, but it’s likely to do that to some methods, and has
CLass/OBject mnemonic).

enchant ? enliven ? enfold ? incorporate ? induct ? :wink:

What about import ?

Regards,

Bill

26

On 6/8/06, [email protected] [email protected] wrote:

On Fri, 9 Jun 2006, Bill K. wrote:

What about import ?
i like it. i think i may have come up with that one a while back too. that,
along with ‘mixin’ - are my favourites so far.

Sensible. You include functionality from a module, you extend an
object with a module, and you import a module wholesale.

Or something nonsensical like that. :wink:

-austin

27

On Fri, 9 Jun 2006, Bill K. wrote:

What about import ?

i like it. i think i may have come up with that one a while back too.
that,
along with ‘mixin’ - are my favourites so far.

cheers.

-a

28

[email protected] wrote:

end

end

class Beanbag
extend (class << Beanable; self; end)
end

Considering the above (which by the way should also have an ‘include
Beanable’), a notation that has some similarity and is available for
use:

class Beanbag
self << Beanable
end

T.

29

Hi,

In message “Re: Why the lack of mixing-in support for Class methods?”
on Fri, 9 Jun 2006 09:22:55 +0900, [email protected] writes:

|Considering the above (which by the way should also have an ‘include
|Beanable’), a notation that has some similarity and is available for
|use:
|
| class Beanbag
| self << Beanable
| end

I like this more than others, but I worry about that this is less
descriptive than other at the same time. For example, how one can
know whether “include” does not injects module methods, where “<<”
does.

						matz.
30

On Jun 8, 2006, at 10:25 PM, Yukihiro M. wrote:

| self << Beanable
| end

I like this more than others, but I worry about that this is less
descriptive than other at the same time. For example, how one can
know whether “include” does not injects module methods, where “<<”
does.

  					matz.

well we have class << self, which involves singleton methods

why not
class Beanbag
include << Beanable
end

which would also involve singleton methods? (Of course then include
has to be a keyword (or “include <<” at least))

31

Yukihiro M. wrote:

| self << Beanable
| end

I like this more than others, but I worry about that this is less
descriptive than other at the same time. For example, how one can
know whether “include” does not injects module methods, where “<<”
does.

 class Beanbag
   include! Beanable
 end

:wink:

Hal

32

Hi –

On Fri, 9 Jun 2006, Phil T. wrote:

…I’m not sure how easy/hard/possible this would be to implement,
though, or if it’s even practical.

I think that’s a dangerous path to go down. self is really just an
alias for a particular object at a particular time, and having it be
more “magic” than that could get messy.

David

33

On 6/8/06, Austin Z. [email protected] wrote:

end
In my mind, #mixin does not capture that, since the process of
#include or #extend is called mixing-in.

No, I don’t have a better name. I thought of #blend, but that’s just
too … ugly.

What about a this approach:

module A
def A.foo
“this method wouldn’t get mixed in”
end
def self.bar
“this method would get mixed in”
end
end

class B
include A
end

B.bar #=> “this method would get mixed in”
B.foo #=> no method error

So the idea would be that if you use ‘def self.<method_name>’ the
method would be mixed in, but if you use ‘def .’ it would not be mixed in.

…I’m not sure how easy/hard/possible this would be to implement,
though, or if it’s even practical.

Another approach would be to so something like:

module A
def self.not_mixable
“not mixed in”
end

mixable
def self.mixed
“mixed in”
end
end

class B
include A
end

B.mixed #=> “mixed in”
B.not_mixable #=> no method error

Phil

34

On Jun 9, 2006, at 5:58 AM, [email protected] wrote:

Then again, I’m not sure what’s wrong with
“extend”, so I’m probably a bit out of the loop on this discussion.

Well, extend takes the instance methods of a module and makes them
class methods on the receiver. People are asking for a natural way
to mix in the class methods of a module, preferably while mixing in
the instance methods as well (as include currently does). In short,
they want to turn this idiom into a one liner:

module MixinForInstanceAndClassMethods
module ClassMethods
# … class methods …
end

extend ClassMethods

def self.included(receiver)
receiver.extend(ClassMethods)
end

… instance methods …

end

class Receiver
include MixinForInstanceAndClassMethods
end

Hope that helps.

James Edward G. II

35

Hal F. wrote:

 class Beanbag
   include! Beanable
 end

I like this and it fits into the current scheme.

36

Yukihiro M. wrote:

I like this more than others, but I worry about that this is less
descriptive than other at the same time. For example, how one can
know whether “include” does not injects module methods, where “<<”
does.

Unfortuantly, as it is, we cannot know. I have seen some bad practices
in the overriding of #include which do not ever inject the module. It’s
weird becuase Ruby reports the module as an ancestor though the module
is totaly devoid of any content, i.e. The #include call was just used
as a “trick” to do something else (usually using class_eval to add
methods directly to the base class/module).

Short of turning include and extend into keywords, I’m not sure there’s
any way to ensure proper behavior. And if that were done, it would
likely create other limitations that may have been useful to more
experienced Rubyists.

T.

37

Hi –

On Fri, 9 Jun 2006, Logan C. wrote:

|use:
matz.

well we have class << self, which involves singleton methods

why not
class Beanbag
include << Beanable
end

which would also involve singleton methods?

I’m not sure << really evokes “connected in some way with singleton
methods”, though. Then again, I’m not sure what’s wrong with
“extend”, so I’m probably a bit out of the loop on this discussion.

(Of course then include has to be a keyword (or “include <<” at
least))

Not necessarily:

class MyModule
def initialize
@list = []
end

def include(*args)
if args.size.zero?
@list
else
@list.concat(args)
end
end
end

m = MyModule.new
m.instance_eval {

include “a”, “b”
include << “c”

p @list # [“a”, “b”, “c”]
}

David

38

On Fri, 9 Jun 2006, [email protected] wrote:

module SomeMethodsIWantSomeClassesToHave
end

module SomeInstanceMethods
end

class C
extend SomeMethodsIWantSomeClassesToHave
include InstanceMethods

s/Instance/SomeInstance/ :slight_smile:

David

39

Hi –

On Fri, 9 Jun 2006, James Edward G. II wrote:

On Jun 9, 2006, at 5:58 AM, [email protected] wrote:

Then again, I’m not sure what’s wrong with
“extend”, so I’m probably a bit out of the loop on this discussion.

Well, extend takes the instance methods of a module and makes them class
methods on the receiver. People are asking for a natural way to mix in the
class methods of a module, preferably while mixing in the instance methods as
well (as include currently does). In short, they want to turn this idiom
into a one liner:

I know (believe me, I’ve been through many iterations of this
discussion :slight_smile: What I really mean is: I don’t see what’s wrong with:

module SomeMethodsIWantSomeClassesToHave
end

module SomeInstanceMethods
end

class C
extend SomeMethodsIWantSomeClassesToHave
include InstanceMethods
end

In other words, I prefer a module design that doesn’t fuse different
modularities together in the first place.

David

40

On Fri, 9 Jun 2006 [email protected] wrote:

extend SomeMethodsIWantSomeClassesToHave
include InstanceMethods
end

In other words, I prefer a module design that doesn’t fuse different
modularities together in the first place.

sometimes they belong together logically:

module Sync
require ‘sync’

 def self.sync m, which = :EX
   module_eval <<-code
     alias_method "__#{ m }__", "#{ m }"

     def #{ m }(*a, &b)
       sync_init
       synchronize(:#{ which }){ __#{ m }__(*a, &b) }
     end
   code
 end

 def sync_init
   extend Sync_m unless Sync_m === self
 end

end

class C
import Sync
sync ‘method_that_needs_to_be_thread_safe’
sync ‘another_method_that_needs_to_be_thread_safe’, :SH
end

obviously one can break them apart, but it’s un-natural. in general
anytime
the imported module introduced instance methods which rely on class
state or
class methods or, as this case does, introduces class methods which rely
in
instance state/methods, it makes logical sense to keep it all in one
bundle.
for me logical orthogonality is by far ruby’s greatest asset and i hate
doing
illogical things in my ruby code - i save that for fortran.

in any case i don’t think anyone thinks anything is ‘wrong’ with
splitting it
up, but it clearly violates DRY to do this

module M
module ClassMethods
end
module InstanceMethods
end
end
class A
include M::InstanceMethods
extend M::ClassMethods
end
class B
include M::InstanceMethods
extend M::ClassMethods
end
class C
include M::InstanceMethods
extend M::ClassMethods
end

vs this

module M
module ClassMethods
end
module InstanceMethods
end
def self.included other
other.extend ClassMethods
other.module_eval{ include InstanceMethods }
end
end
class A
include M
end
class B
include M
end
class C
include M
end

plus, the first case is annoying. if it weren’t, people wouldn’t be
rolling
their own shortcuts left and right - which is kind of what this thread
is
about.

kind regards.

-a