Asp Forum - Object#singleton_class in Ruby 1.9?

Suraj Kurapati

1/30/2009 8:22:00 AM

Hello,

I was under the impresssion that Ruby 1.9 will provide
Object#singleton_class (or #eigen_class or #meta_class), which would
save us the trouble of writing "class << self; self; end" everywhere.

But in Ruby 1.9.1-rc2, I do not see this:

>> RUBY_DESCRIPTION
=> "ruby 1.9.1p0 (2009-01-20 revision 21700) [i686-linux]"

>> Object.instance_methods.grep(/class|singleton|eigen|meta/)
=> [:class, :singleton_methods, :define_singleton_method]

Was Object#singleton_class (or #eigen_class or #meta_class) planned for
Ruby 1.9 or 2.0?

Thanks for your consideration.
--
Posted via http://www.ruby-....

5 Answers

David A. Black

1/30/2009 11:15:00 AM

Hi --

On Fri, 30 Jan 2009, Suraj Kurapati wrote:

> Hello,
>
> I was under the impresssion that Ruby 1.9 will provide
> Object#singleton_class (or #eigen_class or #meta_class), which would
> save us the trouble of writing "class << self; self; end" everywhere.
>
> But in Ruby 1.9.1-rc2, I do not see this:
>
>>> RUBY_DESCRIPTION
> => "ruby 1.9.1p0 (2009-01-20 revision 21700) [i686-linux]"
>
>>> Object.instance_methods.grep(/class|singleton|eigen|meta/)
> => [:class, :singleton_methods, :define_singleton_method]
>
> Was Object#singleton_class (or #eigen_class or #meta_class) planned for
> Ruby 1.9 or 2.0?

Not that I remember hearing about. I'd certainly like to see it.

David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.r...
Coming in 2009: The Well-Grounded Rubyist (http://manning....)

http://www.wis... => Independent, social wishlist management!

Robert Dober

2/3/2009 9:06:00 PM

On Tue, Feb 3, 2009 at 2:44 PM, David A. Black <dblack@rubypal.com> wrote:
> On Tue, 3 Feb 2009, Thomas Sawyer wrote:
>
> class << obj
> def x
> end
> end
>
> module M
> def x
> end
> end
> obj.extend(M) # obj.x is still the first one
>
> Since you can always reopen the singleton class and redefine the
> method, using the singleton class in the first place doesn't mean that
> you're stuck with the original method definition.
>
> I think #extend is highly underutilized. It's one of my favorite Ruby
> techniques. I just don't feel that it has to be in a death-struggle
> with any other techniques.

Well is that not exactly what Tom meant? Maybe someone can update me
here please?
My understanding is that:

If people would use extend instead of class << etc the
"metaprogrammers" (e.g. somebody creating a framework or an extensions
for traits as I did ) could produce code easier just by saying:
As long as you extend your object and classes and never use << my
framework is shielded. If you reopen singleton classes, well you are
at your own.

Cheers
Robert
--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov

David A. Black

2/3/2009 9:25:00 PM

Hi --

On Wed, 4 Feb 2009, Robert Dober wrote:

> On Tue, Feb 3, 2009 at 2:44 PM, David A. Black <dblack@rubypal.com> wrote:
>> On Tue, 3 Feb 2009, Thomas Sawyer wrote:
>>
>> class << obj
>> def x
>> end
>> end
>>
>> module M
>> def x
>> end
>> end
>> obj.extend(M) # obj.x is still the first one
>>
>> Since you can always reopen the singleton class and redefine the
>> method, using the singleton class in the first place doesn't mean that
>> you're stuck with the original method definition.
>>
>> I think #extend is highly underutilized. It's one of my favorite Ruby
>> techniques. I just don't feel that it has to be in a death-struggle
>> with any other techniques.
>
> Well is that not exactly what Tom meant? Maybe someone can update me
> here please?
> My understanding is that:
>
> If people would use extend instead of class << etc the
> "metaprogrammers" (e.g. somebody creating a framework or an extensions
> for traits as I did ) could produce code easier just by saying:
> As long as you extend your object and classes and never use << my
> framework is shielded. If you reopen singleton classes, well you are
> at your own.

It depends what you mean by shielded. If I use a library that extends
my objects with modules, and then I extend those same objects with
other modules that have methods of the same name, then the methods in
the library will be hidden. This is, however, a very unlikely
scenario. But avoiding << isn't a cure-all, if the problem is that two
modules are fighting over a particular method for a particular object.

Nor is this kind of problem specific to singleton methods and
singleton classes, of course. This is why I think it's very tricky to
come up with rules in this area. In the end, it's always going to be
about particular code and particular programming goals.

David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.r...
Coming in 2009: The Well-Grounded Rubyist (http://manning....)

http://www.wis... => Independent, social wishlist management!

Robert Dober

2/4/2009 7:40:00 AM

On Tue, Feb 3, 2009 at 10:25 PM, David A. Black <dblack@rubypal.com> wrote:

> Nor is this kind of problem specific to singleton methods and
> singleton classes, of course. This is why I think it's very tricky to
> come up with rules in this area. In the end, it's always going to be
> about particular code and particular programming goals.
Ah very nicely put, indeed that shows me what I *should* have said:

It is IMHO preferable that, in case of a name conflict, the framework
wins over the application using it. But maybe I am wrong and this is
not much better a scenario? (All boiling down as usual to testing and
testing and well... testing)
Robert

--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov

David A. Black

2/4/2009 12:01:00 PM

Hi --

On Wed, 4 Feb 2009, Robert Dober wrote:

> On Tue, Feb 3, 2009 at 10:25 PM, David A. Black <dblack@rubypal.com> wrote:
>
>> Nor is this kind of problem specific to singleton methods and
>> singleton classes, of course. This is why I think it's very tricky to
>> come up with rules in this area. In the end, it's always going to be
>> about particular code and particular programming goals.
> Ah very nicely put, indeed that shows me what I *should* have said:
>
> It is IMHO preferable that, in case of a name conflict, the framework
> wins over the application using it. But maybe I am wrong and this is
> not much better a scenario?

To be honest, I'm having a hard time even thinking of a case when
exactly this would happen. I'm trying to think what such library code
would look like, and it's hard to picture a reasonable version :-)

> (All boiling down as usual to testing and
> testing and well... testing)

Or, in other words, all boiling down to what the objects actually do
when we send them messages. Funny how it always converges back onto
that, isn't it? :-)

David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.r...
Coming in 2009: The Well-Grounded Rubyist (http://manning....)

http://www.wis... => Independent, social wishlist management!

comp.lang.ruby

Object#singleton_class in Ruby 1.9?

Suraj Kurapati

David A. Black

Robert Dober

David A. Black

Robert Dober

David A. Black

x Login to ForumsZone