Once again looking for my module methods

Ruby
21

“”"
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.

22

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.

yeah! down with inheritance! up with common blocks!

:wink:

-a

23

Hi,

In message “Re: once again looking for my module methods”
on Tue, 21 Mar 2006 12:17:04 +0900, [email protected] writes:

|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, just because the module’s instance methods are appropriate for
|instances of the class. That’s one possible scenario (and it can
|easily be done, already, though I think it’s not necessarily a sign of
|optimal design), but I don’t see why it should be the starting point
|and everything else a deviation from it. See the RCR site for more
|comments from me and others.

Thanks, David. I don’t want to make

include Math

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

						matz.
24

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 methodcos’ 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.

25

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.

26

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.