I was reading through the source code of the DBI module and I saw this
line there.
class << self
What does this statement do?
I asked the same question yesterday...
It is just another way add singleton methods to the outer scope (probably saw this in a module?). So this:
module Foo
class << self
def a; end
def b; end
end
end
is the same as:
module Foo
def Foo.a; end
def Foo.b; end
end
I guess people use this style to organize sets of singleton methods so that they are clearly separated from the rest of the module. (Since methods defined regularly won't be used until the module is mixed in somewhere...) Saves you from having to write the "Foo." part before every method too...
-Jeff
Tim Uckun wrote:
···
I was reading through the source code of the DBI module and I saw this
line there.class << self
What does this statement do?
Hi --
I was reading through the source code of the DBI module and I saw this
line there.class << self
What does this statement do?
In general, this:
class << obj
puts you into a class definition block for the singleton class of obj.
The singleton class of obj is where those methods are stored that are
unique to obj. So it's like a class-definition interface to obj's
unique behaviors.
class << self is just a case where the object whose singleton class
you're gaining access to is the current object (self).
David
···
On Thu, 11 May 2006, Tim Uckun wrote:
--
David A. Black (dblack@wobblini.net)
* Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
> Ruby and Rails consultancy and training
* Author of "Ruby for Rails" from Manning Publications!
> Ruby for Rails
It is just another way add singleton methods to the outer scope
(probably saw this in a module?). So this:
Yes. I first tried to inherit from DBI but I couldn't because it's a
module. I then started reading it because it's a great way to learn a
language.
module Foo
def Foo.a; end
def Foo.b; end
end
Ok I get it. I guess this format is more familiar to my eyes but I can
see how the other way would be a little more economical and organized.
Here's a very interesting read:
http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html
I discovered it yesterday myself
Raph
···
On 5/11/06, Tim Uckun <timuckun@gmail.com> wrote:
> It is just another way add singleton methods to the outer scope
> (probably saw this in a module?). So this:Yes. I first tried to inherit from DBI but I couldn't because it's a
module. I then started reading it because it's a great way to learn a
language.>
> module Foo
> def Foo.a; end
> def Foo.b; end
> endOk I get it. I guess this format is more familiar to my eyes but I can
see how the other way would be a little more economical and organized.
Tim Uckun wrote:
Yes. I first tried to inherit from DBI but I couldn't because it's a
module.
include() it instead. 
···
Raphael Bauduin wrote:
Here's a very interesting read:
http://whytheluckystiff.net/articles/seeingMetaclassesClearly.html
And here's a three-panel cartoon by the same author:
Cheers,
Dave
> Yes. I first tried to inherit from DBI but I couldn't because it's a
> module.include() it instead.
I was going to do that but i still haven't quire wrapped my mind
around mix-ins. I decided on a container model and just declared a
database handle as an instance variable.
The thing that insterests me is the choice to write a module as
opposed to an object. One day I will figure out when to write a
module instead of an object. For now I am just writing objects and
pretending that ruby is java or python. I figure that's good enough
till I learn more about mixins.