Can someone improve on this multiple inheritence methodology


#1

this provide method re-use at both the class and module level. it can
be used
for a kind of multiple inheritence organizational style.

 harp:~ > cat a.rb
 class Module
   def inherit other
     extend other::ClassMethods if defined? other::ClassMethods
     extend other::ModuleMethods if defined? other::ModuleMethods
     include other::ModuleMethods if defined? other::ModuleMethods
     include other::InstanceMethods if defined? 

other::InstanceMethods
include other
end
end

 class A
   module Methods
     module ClassMethods
       def foo; 42; end
     end
     module ModuleMethods
       def bar; "forty-two"; end
     end
     module InstanceMethods
       def foobar; 42.0; end
     end
     def barfoo; "FORTY-TWO"; end
   end
   inherit Methods
 end

 class B
   inherit A::Methods
 end

 module M
   inherit A::Methods
 end

 class C
   inherit M
 end

 b = B::new
 p B::foo
 p B::bar
 p b::bar
 p b::foobar
 p b::barfoo

 c = C::new
 p C::foo
 p C::bar
 p c::bar
 p c::foobar
 p c::barfoo



 harp:~ > ruby a.rb
 42
 "forty-two"
 "forty-two"
 42.0
 "FORTY-TWO"
 42
 "forty-two"
 "forty-two"
 42.0
 "FORTY-TWO"

thoughts?

-a


#2

I like the fact that this gets around the module method inheritance
issue. This is how #include should work to begin with, but without the
extra baggage of modules in modules (and if neccessary add an extra
“don’t inheirt” section indicator in order to have every possibility).

T.


#3

On Thu, 15 Dec 2005, Trans wrote:

I like the fact that this gets around the module method inheritance issue.

right. what i have is actually

module Common
end

module A
inlcude Common
end

module B
inlcude Common
end

and i want to simply say ‘include A’ or ‘include B’ and have it work.
it
doesn’t, of course, because one cannot factor out class methods in this
way
without the self::included hack, which i seem to be writing alot. at
least
this was i can write it once and my module are clear in their intent (to
be
mixins).

This is how #include should work to begin with, but without the extra
baggage of modules in modules (and if neccessary add an extra “don’t
inheirt” section indicator in order to have every possibility).

100% agreed.

regards.

-a


#4

On Thu, 15 Dec 2005 removed_email_address@domain.invalid wrote:

class Module
def inherit other

My main suggestion would be to rename this method. I don’t think this
is an inheritance operation. At least, it seems potentially confusing
to “inherit” a module, since inheritance already means something else
and modules already do other things.

true true. hmmm… how is it different here? you’ll have all the
class_methods and all the instance_methods… and Superclass === self
with
be true…

i’m sure there must be a catch though…

can you think of a better name?

cheers.

-a


#5

Hi –

On Thu, 15 Dec 2005, Ara.T.Howard wrote:

this provide method re-use at both the class and module level. it can be
used
for a kind of multiple inheritence organizational style.

harp:~ > cat a.rb
class Module
def inherit other

My main suggestion would be to rename this method. I don’t think this
is an inheritance operation. At least, it seems potentially confusing
to “inherit” a module, since inheritance already means something else
and modules already do other things.

David


David A. Black
removed_email_address@domain.invalid

“Ruby for Rails”, forthcoming from Manning Publications, April 2006!


#6

On Thu, 15 Dec 2005, Eero S. wrote:

Also, of course, #import, #mix, #combine and #greyskull.
i like mix!

maybe #mixin. anyone know if there are plans for that?

-a


#7

unknown wrote:

On Thu, 15 Dec 2005 removed_email_address@domain.invalid wrote:

class Module
def inherit other

My main suggestion would be to rename this method. I don’t think this
is an inheritance operation. At least, it seems potentially confusing
to “inherit” a module, since inheritance already means something else
and modules already do other things.

true true. hmmm… how is it different here? you’ll have all the
class_methods and all the instance_methods… and Superclass === self
with
be true…

i’m sure there must be a catch though…

can you think of a better name?

Well… #include :slight_smile:
Also, of course, #import, #mix, #combine and #greyskull.

The design itself seems to be fine. An alternative would
be to create an enhanced #include which would take over
if require ‘better-include’ is encountered (until such
time that this makes it to the stdlib).

cheers.

-a

E


#8

On Thu, 15 Dec 2005 removed_email_address@domain.invalid wrote:

But self.superclass == SomeModule won’t be true, nor will anything else that
reflects the singleness of inheritance. I guess my feeling is that since
inheritance is single, calling anything non-single inheritance is more or
less definitely going to cause confusion.

not sure about that… module appear in ancesors and work like
everything
else. for example

 ParentModule === self

but i have a hunch there is something different. it just doesn’t spring
to
mind.

I don’t know… I think I’m sort of terminologied out, temporarily… but
I’ll keep a few brain cells on the case :slight_smile:

:wink:

i’m leaning towards ‘inject’

class C
inject AModule::Methods
end

-a


#9

Hi –

On Thu, 15 Dec 2005, removed_email_address@domain.invalid wrote:

to “inherit” a module, since inheritance already means something else
and modules already do other things.

true true. hmmm… how is it different here? you’ll have all the
class_methods and all the instance_methods… and Superclass === self
with
be true…

But self.superclass == SomeModule won’t be true, nor will anything
else that reflects the singleness of inheritance. I guess my feeling
is that since inheritance is single, calling anything non-single
inheritance is more or less definitely going to cause confusion.

i’m sure there must be a catch though…

can you think of a better name?

I was afraid you’d ask that :slight_smile:

Well… #include :slight_smile:
Also, of course, #import, #mix, #combine and #greyskull.

i like mix!

maybe #mixin. anyone know if there are plans for that?

That’s already in very common currency, meaning essentially an
‘include’ operation (as in, Array mixes in Enumerable, etc.).

I don’t know… I think I’m sort of terminologied out, temporarily…
but I’ll keep a few brain cells on the case :slight_smile:

David


David A. Black
removed_email_address@domain.invalid

“Ruby for Rails”, forthcoming from Manning Publications, April 2006!


#10

On Wed, 21 Dec 2005 removed_email_address@domain.invalid wrote:

** > include other::ModuleMethods if defined?
?
i’m using ModuleMethods to hold methods which can be called on either
instances or classes - like ‘module_method :foo’. so this modules needs
both
to extend the current module and be included in it.

kind regards.

-a


#11

Ara.T.Howard wrote:

this provide method re-use at both the class and module level. it can be used
for a kind of multiple inheritence organizational style.

 harp:~ > cat a.rb
 class Module
   def inherit other
     extend other::ClassMethods if defined? other::ClassMethods
     extend other::ModuleMethods if defined? other::ModuleMethods

** > include other::ModuleMethods if defined?
other::ModuleMethods

     include other::InstanceMethods if defined? other::InstanceMethods
     include other
   end
 end

I did not understand the ‘**’ line. Shouldn’t it be:

  • extend ClassMethods
  • extend ModuleMethods
  • include InstanceMethods
    ?