Need for singleton_methods

Ruby
1

I have trying to learn about this class<<self;self;end and the
class<<self followed by defining the method.I absolutely don’t see
anything which will help this case.I can very well do it directly on the
class …
class Foo
def Foo.bar
end
end

what is the advantage I get by using the class << self notation…

class Foo
class<<self
def bar
end
end
end

This is all confusing .Can any body suggest a simple example with
tangible result to show the advantage.I am pretty sure more
people(nubies) will have this…

I have been doing my home work for the pass 2 days. I found that it is
helpful in inheritance as per the whytheluckystiff.com guy (why’s
poignant guide)…I don’t understand what is the need for even in that
case.If I define the method directly like this

class Foo
def Foo.bar
end
end

class Hoo < Foo
end

I am still OK …Hoo.bar will work…
Any body want to pitch thier thoughts…
THnks
CHinna

2

On Mar 14, 3:26 pm, Chinna K. [email protected] wrote:

class Foo
class<<self
def bar
end
end
end

If you want to use a helper method, like #attr_accessor, for instance,
this form becomes more convenient:

class Foo
class<<self
attr_accessor :bar
end
end

def Foo.bar
end
end

Better:

class Foo
def self.bar
end
end

If you ever change then name of the module, you won’t have to change
it all over the place.

T.

3

Hi –

On Sat, 15 Mar 2008, Chinna K. wrote:

class Hoo < Foo
end

I am still OK …Hoo.bar will work…
Any body want to pitch thier thoughts…

The main thing that’s going on here is that objects are getting the
ability to grow on an individual basis, and that’s a central principle
of Ruby. The way they grow is through the acquisition of methods that
other objects of their class don’t have.

The point of the singleton class is to provide a uniform interface to
the various layers of behavior that make up the object. Whenever you
want to add, override, or undefine methods, you can do it inside a
class definition block – either class C, or class << object.

Also, keep in mind that (as per that last example) it’s not just for
class objects. It’s a general mechanism for implementing per-object
behavior.

David

4

This cannot be a reason since if you make change to Module then you have
change it place where you call as well…say for eg you change Math
Module name Maths… then where ever you are calling Math.sin would have
to be Maths.sin

Better:

class Foo
def self.bar
end
end

If you ever change then name of the module, you won’t have to change
it all over the place.

T.