Once again looking for my module methods

I wonder if there's a way to make several groups of people happy by
allowing this:
module Z
  def method; end
end

class A < Z
end

..which would let modules act as abstract classes if necessary.

···

On 3/21/06, Trans <transfire@gmail.com> wrote:

> I don't think it's a good idea, because I see no reason to favor the
> hypothesis that a module's singleton methods are appropriate
> for a class

What "hypothesis"? It's being used in *practice*.

According to your argument we should not have class method inheritance
either.

T.

yeah! down with inheritance! up with common blocks!

:wink:

-a

···

On Wed, 22 Mar 2006, Trans wrote:

I don't think it's a good idea, because I see no reason to favor the
hypothesis that a module's singleton methods are appropriate
for a class

What "hypothesis"? It's being used in *practice*.

According to your argument we should not have class method inheritance
either.

--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama

Thanks, David. I don't want to make

include Math

at the toplevel to add sin, cos, etc. to Object class.

It already does. They are there you just can't access them b/c they're
private.

  Object.cos(1)
  NoMethodError: undefined method `cos' for Object:Class
          from (irb):1
  irb(main):002:0> include Math
  => Object
  irb(main):003:0> Object.cos(1)
  NoMethodError: private method `cos' called for Object:Class
          from (irb):3
  irb(main):004:0> class << Object
  irb(main):005:1> public :cos
  irb(main):006:1> end
  => #<Class:Object>
  irb(main):007:0> Object.cos(1)
  => 0.54030230586814

T.

Hi --

I wonder if there's a way to make several groups of people happy by
allowing this:
module Z
def method; end
end

class A < Z
end

..which would let modules act as abstract classes if necessary.

There's definitely a school of thought that modules and classes should
be merged, though I am not of it and Matz isn't either :slight_smile:

David

···

On Wed, 22 Mar 2006, Wilson Bilkovich wrote:

On 3/21/06, Trans <transfire@gmail.com> wrote:

I don't think it's a good idea, because I see no reason to favor the
hypothesis that a module's singleton methods are appropriate
for a class

What "hypothesis"? It's being used in *practice*.

According to your argument we should not have class method inheritance
either.

T.

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails

"""
module Z
  def method; end
end

class A < Z
end
"""

Interesting. Although David has taken this to mean a merger of Classes
and Modules, that's not necessarily the case. It simply indicates a
different treatment of said module. It would be as if a method other
than #include were used.

  module Z
    def method; end
  end

  class A
    integrate Z
  end

That really does seem like a win-win solution for all.

Nice catch Wilson!

T.

Speaking of "<<", what about making more use of that piece of syntax?

For example:
class ConcreteThing << Module
end

I don't think that would be precisely "unifying" modules and classes.
I feel pretty comfortable with Ruby these days, and I feel like my
code is highly Ruby-like.
On the other hand, I occasionally miss interfaces and abstract classes
for readability reasons.

···

On 3/21/06, Trans <transfire@gmail.com> wrote:

> Thanks, David. I don't want to make
>
> include Math
>
> at the toplevel to add sin, cos, etc. to Object class.

It already does. They are there you just can't access them b/c they're
private.

  Object.cos(1)
  NoMethodError: undefined method `cos' for Object:Class
          from (irb):1
  irb(main):002:0> include Math
  => Object
  irb(main):003:0> Object.cos(1)
  NoMethodError: private method `cos' called for Object:Class
          from (irb):3
  irb(main):004:0> class << Object
  irb(main):005:1> public :cos
  irb(main):006:1> end
  => #<Class:Object>
  irb(main):007:0> Object.cos(1)
  => 0.54030230586814

T.