Need for singleton_methods

ruby-talk
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

···

--
Posted via http://www.ruby-forum.com/.

2

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

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

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

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.

···

On Mar 14, 3:26 pm, Chinna Karuppan <chinnakarup...@gmail.com> wrote:

3

Hi --

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

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

class Foo
class<<self
def bar
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

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

···

On Sat, 15 Mar 2008, Chinna Karuppan wrote:

--
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details. Berlin dates coming soon!

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.

--
Posted via http://www.ruby-forum.com/\.