Forum: Ruby can someone improve on this multiple inheritence methodology

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 Ara.T.Howard (Guest)
on 2005-12-14 22:08
(Received via mailing list)
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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2005-12-15 01:09
(Received via mailing list)
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.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-15 04:37
(Received via mailing list)
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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-15 05:19
(Received via mailing list)
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
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-15 05:22
(Received via mailing list)
On Thu, 15 Dec 2005 dblack@wobblini.net 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
Fe9b2d0628c0943af374b2fe5b320a82?d=identicon&s=25 Eero Saynatkari (rue)
on 2005-12-15 05:35
unknown wrote:
> On Thu, 15 Dec 2005 dblack@wobblini.net 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 :)
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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-15 05:55
(Received via mailing list)
On Thu, 15 Dec 2005, Eero Saynatkari wrote:

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

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

-a
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2005-12-15 06:34
(Received via mailing list)
Hi --

On Thu, 15 Dec 2005, ara.t.howard@noaa.gov 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 :-)

>> Well.. #include :)
>> 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 :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-15 06:55
(Received via mailing list)
On Thu, 15 Dec 2005 dblack@wobblini.net 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 :-)

;-)

i'm leaning towards 'inject'

   class C
     inject AModule::Methods
   end

-a
Fe57662c550fb3cce44c398ddf2dd706?d=identicon&s=25 unknown (Guest)
on 2005-12-21 06:08
(Received via mailing list)
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
?
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2005-12-21 16:28
(Received via mailing list)
On Wed, 21 Dec 2005 itsme213@hotmail.com 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
This topic is locked and can not be replied to.