Forum: Ruby Object#singleton_class in Ruby 1.9?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-30 09:24
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.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-30 12:18
(Received via mailing list)
Hi --

On Fri, 30 Jan 2009, Suraj Kurapati wrote:

>
>>> 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.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2009-01-30 16:32
(Received via mailing list)
Hi,

In message "Re: Object#singleton_class in Ruby 1.9?"
    on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black"
<dblack@rubypal.com> writes:

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

We still don't have consensus on the name.  eigenclass?
In that case, should we rename singleton_method to eigenmethod?

              matz.
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-01-30 16:51
(Received via mailing list)
On Fri, Jan 30, 2009 at 10:28 AM, Yukihiro Matsumoto
<matz@ruby-lang.org> wrote:
> We still don't have consensus on the name.  eigenclass?
> In that case, should we rename singleton_method to eigenmethod?

I wonder if this controversy has died down.   There are people with
their favorites, sure, but does anyone really oppose singleton_class?

-greg
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-01-30 16:56
(Received via mailing list)
On Jan 30, 2009, at 9:47 AM, Gregory Brown wrote:

>> |> Ruby 1.9 or 2.0?
>> |
>> |Not that I remember hearing about. I'd certainly like to see it.
>>
>> We still don't have consensus on the name.  eigenclass?
>> In that case, should we rename singleton_method to eigenmethod?
>
> I wonder if this controversy has died down.   There are people with
> their favorites, sure, but does anyone really oppose singleton_class?

I'm for singleton_class.  It's what the official documentation has
used for a long time now.  It's also not like it will be the only
overloaded term in computing.

James Edward Gray II
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 Gary Wright (Guest)
on 2009-01-30 17:50
(Received via mailing list)
On Jan 30, 2009, at 10:53 AM, James Gray wrote:
> I'm for singleton_class.  It's what the official documentation has
> used for a long time now.  It's also not like it will be the only
> overloaded term in computing.


eigenton_class?  :-)

eigen_class or singleton_class doesn't really matter to
me at this point but I do feel strongly that the object
returned by:

  (class <<obj; self; end)

should be available via a simple method call rather
than only via that expression.

Gary Wright
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-30 18:46
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Object#singleton_class in Ruby 1.9?"
>     on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black"
> <dblack@rubypal.com> writes:
>
> |> 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.
>
> We still don't have consensus on the name.  eigenclass?
> In that case, should we rename singleton_method to eigenmethod?

Since you make mention of "eigenclass", that would seem to be your bent.
And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it!

It may be Germanic, but I for one like the shorter method names anyway.
And certainly _Why has done enough for Ruby to deserve a little of his
charm to shine through the language... it will just give Ruby another
unique touch that her fans can revel in. Not to mention, no more
Singleton vs. singleton controversy.

Big smiles and all thumbs up,

T.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-30 18:53
Yukihiro Matsumoto wrote:
> Hi,
>
> In message "Re: Object#singleton_class in Ruby 1.9?"
>     on Fri, 30 Jan 2009 20:15:17 +0900, "David A. Black"
> <dblack@rubypal.com> writes:
>
> |> 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.
>
> We still don't have consensus on the name.  eigenclass?

Sorry, I only mentioned the other names because they were all proposed
when we first discussed this (back in 2006, I think).  Ruby was the
first language where I learned the concept of "singleton class" (not the
design pattern) so I think it makes sense to keep that name.

> In that case, should we rename singleton_method to eigenmethod?

Is this not a larger (disruptive) change than simply adding a new
Object#singleton_class method?

Thanks for your consideration.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-30 18:53
(Received via mailing list)
Hi --

On Sat, 31 Jan 2009, Yukihiro Matsumoto wrote:

> We still don't have consensus on the name.  eigenclass?
> In that case, should we rename singleton_method to eigenmethod?

No, *please* don't. It would mean having to re-edit books as well as
code.... There's been enough change recently :-)


David

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

http://www.wishsight.com => Independent, social wishlist management!
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-30 18:59
Thomas Sawyer wrote:
> Yukihiro Matsumoto wrote:
>> We still don't have consensus on the name.  eigenclass?
>> In that case, should we rename singleton_method to eigenmethod?
>
> Since you make mention of "eigenclass", that would seem to be your bent.
> And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it!

In that case, could we make the names more readable by adding an
underscore after "eigen"?  I find it more difficult to parse the names
otherwise.

Object#eigen_class
Object#eigen_methods
Object#define_eigen_method

> Not to mention, no more Singleton vs. singleton controversy.

This is indeed a good benefit.

Thanks for your consideration.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-30 20:18
Suraj Kurapati wrote:
> Thomas Sawyer wrote:
>> Yukihiro Matsumoto wrote:
>>> We still don't have consensus on the name.  eigenclass?
>>> In that case, should we rename singleton_method to eigenmethod?
>>
>> Since you make mention of "eigenclass", that would seem to be your bent.
>> And I say, go for it! "eigenmethod"? Fantastic! Do it, do it, do it!
>
> In that case, could we make the names more readable by adding an
> underscore after "eigen"?  I find it more difficult to parse the names
> otherwise.
>
> Object#eigen_class
> Object#eigen_methods
> Object#define_eigen_method

Interesting, I find the other more readable, 'class' is like a suffix to
me, along the lines of 'name' in methods like #basename and #dirname.

Just personal preference of course. I'm don't think there is any true
rational for one over the other.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-30 20:20
David A. Black wrote:
> Hi --
>
> On Sat, 31 Jan 2009, Yukihiro Matsumoto wrote:
>
>> We still don't have consensus on the name.  eigenclass?
>> In that case, should we rename singleton_method to eigenmethod?
>
> No, *please* don't. It would mean having to re-edit books as well as
> code.... There's been enough change recently :-)

David! How else are you supposed to sell 2nd and 3rd editions! ;)

T.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-30 21:00
Thomas Sawyer wrote:
> Suraj Kurapati wrote:
>> In that case, could we make the names more readable by adding an
>> underscore after "eigen"?  I find it more difficult to parse the names
>> otherwise.
>>
>> Object#eigen_class
>> Object#eigen_methods
>> Object#define_eigen_method
>
> Interesting, I find the other more readable, 'class' is like a suffix to
> me, along the lines of 'name' in methods like #basename and #dirname.

The problem I have with words like "basename" is that, to me, they are
not actually words.  For example, I pronounce "basename" as two separate
words "base, name" (with a brief pause in between) not as a continuous
word "basen-a-me" (without any pause in between).

The same applies to "dirname", which I pronounce as "dir, name".  In
contrast, "singleton" is actually pronounced continuously as
"sin-gel-ton", not as "single, ton", so I have no need to insert
underscores in that word.

In short, how a word is pronounced tells me when to insert underscores.

> Just personal preference of course. I'm don't think there is any true
> rational for one over the other.

I beg to differ and I think there is a rationale (see above).

Thanks for your consideration.
Aaca034456897ccbc8bb14953c4a41c1?d=identicon&s=25 Radosław Bułat (radarek)
on 2009-01-30 21:59
(Received via mailing list)
On Fri, Jan 30, 2009 at 4:47 PM, Gregory Brown
<gregory.t.brown@gmail.com> wrote:
> I wonder if this controversy has died down.   There are people with
> their favorites, sure, but does anyone really oppose singleton_class?

singleton_class is definitely the best (specially when we consider
that word 'signleton' already appeared in ruby). What I don't like in
"eigenclass" is that it's not english word (AFAIR it's from germany
'egein' word).

--
Pozdrawiam

Rados³aw Bu³at
http://radarek.jogger.pl - mój blog
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-30 22:54
Suraj Kurapati wrote:

>> Just personal preference of course. I'm don't think there is any true
>> rationale for one over the other.
>
> I beg to differ and I think there is a rationale (see above).

Never_the_less this is English, a close relative of German, and it these
languages conjoined words are common_place.

T.
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-30 23:24
Thomas Sawyer wrote:
> Suraj Kurapati wrote:
>
>>> Just personal preference of course. I'm don't think there is any true
>>> rationale for one over the other.
>>
>> I beg to differ and I think there is a rationale (see above).
>
> Never_the_less this is English, a close relative of German, and in these
> languages conjoined words are common_place.

Good point and excellent illustration!  Until seeing your example, I
never realized how well underscores flow with text, in comparison to
hyphens:

  nevertheless  vs.  never-the-less  vs.  never_the_less  vs.
neverTheLess
  commonplace   vs.  common-place    vs.  common_place    vs.
commonPlace

Of all the typographic conventions listed in the above example, I
heavily prefer snake_case, which is thankfully prevalent in Ruby.  This
is one aspect of Ruby that I found very attractive, compared to, say,
Python, where the firstconventionintheaboveexample is prevalent.  (A
personal preference, I agree.)

Generally speaking, it's surprising that a better typographic convention
would arise from computer science rather than from literature.  Perhaps
we may someday find that, in the increasingly digital future, people
would begin using under_scores as an alternative to the traditional
process of compound words being initially hyphenated (e.g. under-score)
and later not hyphenated (e.g. underscore).

Cheers.
E088bb5c80fd3c4fd02c2020cdacbaf0?d=identicon&s=25 Jesús Gabriel y Galán (Guest)
on 2009-01-31 00:01
(Received via mailing list)
On Fri, Jan 30, 2009 at 5:46 PM, Gary Wright <gwtmp01@mac.com> wrote:
> eigen_class or singleton_class doesn't really matter to
> me at this point but I do feel strongly that the object
> returned by:
>
>        (class <<obj; self; end)
>
> should be available via a simple method call rather
> than only via that expression.

I completely agree with this point of view. I don't mind which name
gets chosen, but please, choose one :-).

Jesus.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-31 06:00
Jesús Gabriel y Galán wrote:
> On Fri, Jan 30, 2009 at 5:46 PM, Gary Wright <gwtmp01@mac.com> wrote:
>> eigen_class or singleton_class doesn't really matter to
>> me at this point but I do feel strongly that the object
>> returned by:
>>
>>        (class <<obj; self; end)
>>
>> should be available via a simple method call rather
>> than only via that expression.
>
> I completely agree with this point of view. I don't mind which name
> gets chosen, but please, choose one :-).
>
> Jesus.

I thought you were making an exclamation, until I realized that was
actually your name. :)

Hope that doesn't offend --with a name like mine I know how it can be.
It just gave me a good laugh, so I thought I'd share it.

T.
E088bb5c80fd3c4fd02c2020cdacbaf0?d=identicon&s=25 Jesús Gabriel y Galán (Guest)
on 2009-01-31 11:29
(Received via mailing list)
On Sat, Jan 31, 2009 at 6:06 AM, Thomas Sawyer <transfire@gmail.com>
wrote:
> Jesús Gabriel y Galán wrote:

> I thought you were making an exclamation, until I realized that was
> actually your name. :)
>
> Hope that doesn't offend --with a name like mine I know how it can be.
> It just gave me a good laugh, so I thought I'd share it.

No problem. In Spain my name is used as an exclamation when someone
sneezes, so I'm pretty much used to these kind of things. In any case,
I also find it funny sometimes...

Jesus !

PS: I might start changing the dot for an exclamation mark in my
signature :-)
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2009-01-31 14:13
(Received via mailing list)
On Fri, Jan 30, 2009 at 3:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org>
wrote:
> We still don't have consensus on the name.  eigenclass?
> In that case, should we rename singleton_method to eigenmethod?
>
>                                                        matz.

Personally, I prefer singleton_class. But I would rather it had an
official name than my preference held anything up.

I suspect there is a strong consensus that it should be named,
whatever the name. I doubt we'll ever get consensus on ~what~ that
name should be. :)

Regards,
Sean
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 Gregory Brown (Guest)
on 2009-01-31 18:18
(Received via mailing list)
On Sat, Jan 31, 2009 at 8:12 AM, Sean O'Halpin <sean.ohalpin@gmail.com>
wrote:
>>
> name should be. :)
Definitely.  I was implying that I don't think *too* many people hate
singleton_class, but don't get me wrong, even if matz added
Object#matz_is_awesome and had it do this operation, I'd be happy. :)

-greg
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-01-31 19:18
(Received via mailing list)
On Fri, Jan 30, 2009 at 4:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org>
wrote:
> We still don't have consensus on the name.  eigenclass?
> In that case, should we rename singleton_method to eigenmethod?
>
>                                                        matz.

Actually I am totally against it, in core that is. It would be nice to
have a standard library extension for this, e.g. meta-ruby.
I was really impressed about by David's keynote at Rubyconf. Just
thought to share this thoughts in case I am not a minority.
Cheers
Robert
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-01-31 21:03
Robert Dober wrote:
> On Fri, Jan 30, 2009 at 4:28 PM, Yukihiro Matsumoto <matz@ruby-lang.org>
> wrote:
>> We still don't have consensus on the name.  eigenclass?
>> In that case, should we rename singleton_method to eigenmethod?
>>
>>                                                        matz.
>
> Actually I am totally against it, in core that is. It would be nice to
> have a standard library extension for this, e.g. meta-ruby.
> I was really impressed about by David's keynote at Rubyconf. Just
> thought to share this thoughts in case I am not a minority.

You are against having a method altogether, you mean?

I take it because of the very nature singleton_methods / eigenmethods.
And, I'm guessing, you prescribe to the idea that the only good way to
the singleton "space" is to include modules into it, rather than
defining methods directly. There was a blog post around somewhere to
that effect. It was a good article. I wish I could dig it up now, but
I'm not finding it. Perhaps someone else has the link? In any case, if
that's what you mean, then I generally agree. That article was right,
there rarely is a good reason to define methods directly into the
singleton, one should be including a module with the methods defined in
it instead. The only exception may be class-level methods, but even then
using #extend deserves more merit.

Taking that idea to heart perhaps a reorientation on the matter is
warranted.
Consider this form in place of the usual 'class << self':

  class X
    extend Module.new {
      ...
    }
  end

Not quite as elegant since we can't use do...end. But if #extend could
take a block:

  class X
    extend do
      ...
    end
  end

Then the issue becomes transparent. Even for regular objects:

  obj.extend do
    ...
  end

This is not to say that a singleton_class/eigenclass method would never
be of use, but it would certainly mitigate the need for it a great deal.
(One might also take away from this that a better name for it, if it
were given a method name, would be #extension, but I mention that only
as an aside.)

T.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-31 21:16
(Received via mailing list)
On Sun, 1 Feb 2009, Robert Dober wrote:

>>
>> We still don't have consensus on the name.  eigenclass?
>> In that case, should we rename singleton_method to eigenmethod?
>>
>>                                                        matz.
>
> Actually I am totally against it, in core that is. It would be nice to
> have a standard library extension for this, e.g. meta-ruby.
> I was really impressed about by David's keynote at Rubyconf. Just
> thought to share this thoughts in case I am not a minority.

I'd like to have a singleton_class method, but even if there isn't
one, I would definitely not like a meta-ruby standard extension. It
suggests much too clear a separation between programming and
metaprogramming in Ruby, whereas part of the coolness of the language
is how interoperative it all is (e.g., the very fact that singleton
methods are stored in classes, which in turn fit into the whole
class/object model in a predictable way).


David

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

http://www.wishsight.com => Independent, social wishlist management!
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-01-31 21:39
(Received via mailing list)
On Jan 31, 2009, at 11:18 AM, Gregory Brown wrote:

>>> |> Was Object#singleton_class (or #eigen_class or #meta_class)
>> Personally, I prefer singleton_class. But I would rather it had an
>> official name than my preference held anything up.
>>
>> I suspect there is a strong consensus that it should be named,
>> whatever the name. I doubt we'll ever get consensus on ~what~ that
>> name should be. :)
>
> Definitely.  I was implying that I don't think *too* many people hate
> singleton_class, but don't get me wrong, even if matz added
> Object#matz_is_awesome and had it do this operation, I'd be happy. :)

I've changing my vote.  I now want:

   matz_class()

No one can beat that.  :)

James Edward Gray II
Bc368ef524130e8d0deb386de961e24a?d=identicon&s=25 Suraj Kurapati (snk)
on 2009-01-31 22:02
James Gray wrote:
> Gregory Brown wrote:
>> Matz wrote:
>>> We still don't have consensus on the name.  eigenclass?
>>> In that case, should we rename singleton_method to eigenmethod?
>>
>> I wonder if this controversy has died down.   There are people with
>> their favorites, sure, but does anyone really oppose singleton_class?
>
> I'm for singleton_class.  It's what the official documentation has
> used for a long time now.  It's also not like it will be the only
> overloaded term in computing.

I filed a request for Object#singleton_class in the Ruby Issue Tracking
System:

  http://redmine.ruby-lang.org/issues/show/1082

Thanks for your consideration.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-01-31 22:24
(Received via mailing list)
Hi --

On Sun, 1 Feb 2009, Suraj Kurapati wrote:

>> used for a long time now.  It's also not like it will be the only
>> overloaded term in computing.
>
> I filed a request for Object#singleton_class in the Ruby Issue Tracking
> System:
>
>  http://redmine.ruby-lang.org/issues/show/1082

Good ol' RCR 231, or whatever it was :-)


David

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

http://www.wishsight.com => Independent, social wishlist management!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-01-31 23:03
(Received via mailing list)
On Sat, Jan 31, 2009 at 9:13 PM, David A. Black <dblack@rubypal.com>
wrote:
<snip>
> I'd like to have a singleton_class method, but even if there isn't
> one, I would definitely not like a meta-ruby standard extension. It
> suggests much too clear a separation between programming and
> metaprogramming in Ruby, whereas part of the coolness of the language
> is how interoperative it all is (e.g., the very fact that singleton
> methods are stored in classes, which in turn fit into the whole
> class/object model in a predictable way).
Well please let me rephrase this:

I think #singleton_class is a great name. I want it, but rather than
in core in a standard library, or even a core class.
However that consideration was OT - 4 which I apologize - and it might
indeed be worth a discussion for 2.0 if 'nuff people think like that.

Back OnT, I really think it is too late to change #singleton_class it
has become so much used in Ruby's jargon.
I am well aware of the ambiguity with the Singleton pattern, but I
feel it is enough related to still be the ideal choice.

R.
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2009-02-01 09:03
(Received via mailing list)
On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com>
wrote:
[snip]
>
>  end
>

I like this - how do you see it working alongside the proposed
#class_extension from a while ago?

I guess #extend would work as above (i.e. defines singleton methods on
instances), where #class_extension (or #class_extend?) methods/modules
would both extend a class and be inherited by subclasses. I forget
where the discussions on module inheritance ended up. Would you have a
#module_extend method too or would #class_extension work for both
classes and modules (in which case it should be renamed or alased)?

> This is not to say that a singleton_class/eigenclass method would never
> be of use, but it would certainly mitigate the need for it a great deal.
> (One might also take away from this that a better name for it, if it
> were given a method name, would be #extension, but I mention that only
> as an aside.)

I think you're onto something here - conceptually, #extend, singleton
methods and the-class-that-cannot-be-named are closely related but you
wouldn't know that from their names (or lack of them).

Perhaps #extension_class?

Regards,
Sean
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-01 13:04
(Received via mailing list)
Hi --

On Sun, 1 Feb 2009, Sean O'Halpin wrote:

>> Not quite as elegant since we can't use do...end. But if #extend could
>>  obj.extend do
>>    ...
>>  end
>>
>
> I like this - how do you see it working alongside the proposed
> #class_extension from a while ago?
>
> I guess #extend would work as above (i.e. defines singleton methods on
> instances), where #class_extension (or #class_extend?) methods/modules
> would both extend a class and be inherited by subclasses. I forget

I wouldn't want to see 'extend' start to mean both adding a module to
the lookup path, and adding methods to the singleton class, depending
on the context. I guess obj.extend do ... could create an anonymous
module, though I've never had an issue with just creating it with
Module.new or using a named module.

> I think you're onto something here - conceptually, #extend, singleton
> methods and the-class-that-cannot-be-named are closely related but you
> wouldn't know that from their names (or lack of them).

They're related conceptually but they also fit into the object model
nicely: every method is defined in a class or module; every object has
a lookup path of classes and modules. I know Matz has said that the
main thrust of per-object behavior is per-object behavior, and that
the way it's implemented (singleton class, which, like other classes,
can include modules) is secondary, but there's a tremendous advantage
to having it blend into the overall landscape, I think. I've seen
literally hundreds of "Ah ha!" moments where people suddenly grasp the
whole per-object thing because once you get the idea of every object
having a singleton class, you don't have to learn anything else new
(with regard to #extend, etc.).


David

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

http://www.wishsight.com => Independent, social wishlist management!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-01 13:41
(Received via mailing list)
On Sun, Feb 1, 2009 at 9:02 AM, Sean O'Halpin <sean.ohalpin@gmail.com>
wrote:
>> Not quite as elegant since we can't use do...end. But if #extend could
We surely can!
>> take a block:
>>
>>  class X
>>    extend do
>>      ...
>>    end
>>  end
>>
>> Then the issue becomes transparent. Even for regular objects:
>>
module Kernel
  alias_method :__extend__, :extend
  def extend mod=nil, &blk
    __extend__( mod || Module::new( &blk ) )
    self
  end
end

class A
  extend do
    def a;42 end
  end
end

a = Object::new.extend do
  def b; 49 end
end
I believe that these things are better done to your own taste and
shell not make the core larger as it is already, because there simply
is no account for taste.

HTH
Robert
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2009-02-01 15:54
(Received via mailing list)
On Sun, Feb 1, 2009 at 12:03 PM, David A. Black <dblack@rubypal.com>
wrote:
>
> They're related conceptually but they also fit into the object model
> nicely: every method is defined in a class or module; every object has
> a lookup path of classes and modules. I know Matz has said that the
> main thrust of per-object behavior is per-object behavior, and that
> the way it's implemented (singleton class, which, like other classes,
> can include modules) is secondary, but there's a tremendous advantage
> to having it blend into the overall landscape

I agree. After all, subclasses lookup class methods in a parent
class's singleton class and clones inherit from an instance's, e.g.

class A
  def self.foo
    "foo"
  end
end
class B < A
end
a = A.new
def a.foo
  "bar"
end
b = a.clone
puts B.foo
puts b.foo

# >> foo
# >> bar

That is hardly secondary behaviour. We can access an instance's class
by name (via object.class) - why not the singleton (or extension)
class?

> I think. I've seen
> literally hundreds of "Ah ha!" moments where people suddenly grasp the
> whole per-object thing because once you get the idea of every object
> having a singleton class, you don't have to learn anything else new
> (with regard to #extend, etc.).

Well, not hundreds in my case, but it's definitely one of those
epiphany moments (along with 'classes are objects too'). I think
naming the elements involved similarly (extend, extension_class,
extension_methods, etc.) would help clarify the relationship between
these concepts.

(As an aside - why is there no method #extended_modules analogous to
#included_modules?)

Regards,
Sean
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-01 20:43
(Received via mailing list)
Hi --

On Sun, 1 Feb 2009, Sean O'Halpin wrote:

> I agree. After all, subclasses lookup class methods in a parent
> def a.foo
> by name (via object.class) - why not the singleton (or extension)
> naming the elements involved similarly (extend, extension_class,
> extension_methods, etc.) would help clarify the relationship between
> these concepts.

But 'extend' already means something: add a module to the lookup path.
The module that gets added is a completely different object from the
singleton class, and you can extend an object with any number of
modules, anonymous or otherwise. So there's no special identity
between the 'extend' operation and the singleton class. There's a
relation, in the sense that obj.extend(M) is like class << obj;
include M; end, but I don't think there's any reason to name the
singleton class itself in honor of the fact that there's a method
called extend that operates on it, if you see what I mean.


David

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

http://www.wishsight.com => Independent, social wishlist management!
E1d641bfe4071a5413bac781f06d3fd1?d=identicon&s=25 Sean O'halpin (sean)
on 2009-02-01 23:46
(Received via mailing list)
On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack@rubypal.com>
wrote:

[snip]

> But 'extend' already means something: add a module to the lookup path.

Yes - to the special lookup path shared by subclasses qua instances and
clones.

> The module that gets added is a completely different object from the
> singleton class, and you can extend an object with any number of
> modules, anonymous or otherwise.

Well, yes, that's understood :)

> So there's no special identity
> between the 'extend' operation and the singleton class.

I'm not saying there's an identity - I'm saying that extend and the
singleton class are closely related concepts.

>  There's a
> relation, in the sense that obj.extend(M) is like class << obj;
> include M; end, but I don't think there's any reason to name the
> singleton class itself in honor of the fact that there's a method
> called extend that operates on it, if you see what I mean.

I do see what you mean. However, the relationship between #extend and
the singleton class
is much closer than you allow. The singleton class is the thing that's
extended. There are no
other methods that operate exclusively on the singleton class. In
fact, the singleton class springs
into existence to accommodate an extend if it's not already there.

On reading Trans' post, I was struck that extension_class, i.e. the
site of extensions, would be a good name to unify these concepts.
But I'd be happy with any name.

Regards,
Sean
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-02 03:33
David A. Black wrote:
> I wouldn't want to see 'extend' start to mean both adding a module to
> the lookup path, and adding methods to the singleton class, depending
> on the context. I guess obj.extend do ... could create an anonymous
> module, though I've never had an issue with just creating it with
> Module.new or using a named module.

Ah, sorry I wasn't more clear. Yes, I meant it would create an anonymous
module, so as to promote good coding practices. And I agree, it isn't
that hard to use Module.new or name the module, nevertheless we see the
singleton being used directly far too often b/c it is more convenient,
even when having to define our own #singleton_method. And that's the
point of the suggestion, to make it more convenient to #extend rather
than #class_eval on the singleton class. Indeed (I wish I could find
that article) one can make a good case that the singleton class should
never have methods directly defined in it; always use a module.

T.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-02 03:51
Sean O'halpin wrote:
> On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com>
> wrote:
> [snip]
>>
>>  end
>>
>
> I like this - how do you see it working alongside the proposed
> #class_extension from a while ago?
>
> I guess #extend would work as above (i.e. defines singleton methods on
> instances), where #class_extension (or #class_extend?) methods/modules
> would both extend a class and be inherited by subclasses. I forget
> where the discussions on module inheritance ended up. Would you have a
> #module_extend method too or would #class_extension work for both
> classes and modules (in which case it should be renamed or alased)?

Hey, that's a really good point. #class_extension is very much the same
thing, but specifically designed to allow classes to carry the modules
behavior through the class-level hierarchy. So accordingly a better name
would be #class_extend. But as with the original, I still think that
this doesn't convey enough of what it actually does to the inheritance
chain, and likewise why #module_extend doesn't really make sense. But a
concise name for #extend_and _propogate_through_the_class_hierarchy
seems elusive.

> I think you're onto something here - conceptually, #extend, singleton
> methods and the-class-that-cannot-be-named are closely related but you
> wouldn't know that from their names (or lack of them).
>
> Perhaps #extension_class?

My goodness, when you put it like that it does seem rather obvious. I
wonder why no one has ever thought of that before.

T.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-02 13:30
(Received via mailing list)
Hi --

On Mon, 2 Feb 2009, Sean O'Halpin wrote:

> On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack@rubypal.com> wrote:
>
> [snip]
>
>> But 'extend' already means something: add a module to the lookup path.
>
> Yes - to the special lookup path shared by subclasses qua instances and clones.

I'm not sure what you mean by special. Every object has only one
lookup path, and the singleton class is just placed along that path.
Do you mean the special class of singleton classes of class objects?
(The thing where their subclasses share the singleton methods.)

> singleton class are closely related concepts.
Yes, but singleton class and non-singleton class are also closely
related. So are class and module, array and hash, integer and float...
but I wouldn't merge their terminology :-)

> other methods that operate exclusively on the singleton class. In
> fact, the singleton class springs
> into existence to accommodate an extend if it's not already there.

But I wouldn't want to rename Class to IncludeClass, just because
there's an include operation especially designed for classes. I know
there's a bit more going on than that: the idea of "extending" an
object's capabilities is always present, in some form, with all this
per-object behavior in some form. But since there's already an #extend
method, I think the term is potentially too flattening, so to speak.
I'd like to be able to refer to the singleton class without seeming to
refer to the process of including modules in it, which may or may not
happen (via extend or include).

> On reading Trans' post, I was struck that extension_class, i.e. the
> site of extensions, would be a good name to unify these concepts.
> But I'd be happy with any name.

With the disclaimer that I consider there not to be a naming problem
(except for the question of whether 'singleton class' is the right
name in the class of Class objects, which grant singleton class access
to their subclass objects), I'm starting to think of 'e_class'.
Extension, extra, eigen... it's a duck-typed name :-)


David

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

http://www.wishsight.com => Independent, social wishlist management!
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-02 13:32
(Received via mailing list)
Hi --

On Mon, 2 Feb 2009, Thomas Sawyer wrote:

> singleton being used directly far too often b/c it is more convenient,
> even when having to define our own #singleton_method. And that's the
> point of the suggestion, to make it more convenient to #extend rather
> than #class_eval on the singleton class. Indeed (I wish I could find
> that article) one can make a good case that the singleton class should
> never have methods directly defined in it; always use a module.

I'd be interested in seeing that article if you can find it. It
doesn't strike me right off as a convincing idea, but the reasoning
would be interesting to see.


David

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

http://www.wishsight.com => Independent, social wishlist management!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-02 17:20
(Received via mailing list)
On Mon, Feb 2, 2009 at 3:33 AM, Thomas Sawyer <transfire@gmail.com>
wrote:
ed module.
>
> Ah, sorry I wasn't more clear. Yes, I meant it would create an anonymous
> module, so as to promote good coding practices. And I agree, it isn't
> that hard to use Module.new or name the module, nevertheless we see the
> singleton being used directly far too often b/c it is more convenient,
> even when having to define our own #singleton_method. And that's the
> point of the suggestion, to make it more convenient to #extend rather
> than #class_eval on the singleton class. Indeed (I wish I could find
> that article) one can make a good case that the singleton class should
> never have methods directly defined in it; always use a module.
Too bad you cannot find the article. I wonder especially if the
rationale behind that "dogma" was based on performance ( hopefully not
) or design principles.

Cheers
R.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-02 18:07
David A. Black wrote:
> I'd be interested in seeing that article if you can find it. It
> doesn't strike me right off as a convincing idea, but the reasoning
> would be interesting to see.

Yea I found it!

http://blog.jayfields.com/2008/07/ruby-underuse-of...
http://blog.jayfields.com/2008/04/extend-modules-i...

Should have followed my gut from the get-go. I suspected it was Jay :)

T.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2009-02-02 18:15
(Received via mailing list)
On Feb 2, 2009, at 11:07 AM, Thomas Sawyer wrote:

> David A. Black wrote:
>> I'd be interested in seeing that article if you can find it. It
>> doesn't strike me right off as a convincing idea, but the reasoning
>> would be interesting to see.
>
> Yea I found it!
>
> http://blog.jayfields.com/2008/07/ruby-underuse-of...
> http://blog.jayfields.com/2008/04/extend-modules-i...

Those are great reading.  Thanks for sharing.

James Edward Gray II
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-02 20:07
(Received via mailing list)
Hi --

On Tue, 3 Feb 2009, Thomas Sawyer wrote:

> David A. Black wrote:
>> I'd be interested in seeing that article if you can find it. It
>> doesn't strike me right off as a convincing idea, but the reasoning
>> would be interesting to see.
>
> Yea I found it!
>
> http://blog.jayfields.com/2008/07/ruby-underuse-of...
> http://blog.jayfields.com/2008/04/extend-modules-i...

I think it's very good advice for many situations (#extend has always
been my favorite technique for changing the behavior of core objects,
for example). I don't think it's necessary, though, to choose one over
the other in an exclusive sense. This doesn't bother me:

   class C
     class << self
       def x
       end

       def y
       end
     end
   end

etc. Jay's example with extending an object with two modules, so that
the most recent one "wins" (whereas all modules "lose" if the method
in question is defined in the singleton class) is very convincing,
though again I wouldn't necessarily treat it as a reason never to
define a method in the singleton class. I'd say it's more that you
want to know what the ramifications of each technique are, and then
choose the one you want. In that sense it's analogous (though not
identical) to the non-singleton case, where a method defined in a
class "wins", for the instances of the class, over definitions in
included modules. That can be good, or not; it depends on what you're
trying to do.

It all comes down to mastery of the order of method lookup, which then
allows you to do pretty much any permutation.


David

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

http://www.wishsight.com => Independent, social wishlist management!
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Thomas Sawyer (7rans)
on 2009-02-03 13:53
David A. Black wrote:

> etc. Jay's example with extending an object with two modules, so that
> the most recent one "wins" (whereas all modules "lose" if the method
> in question is defined in the singleton class) is very convincing,
> though again I wouldn't necessarily treat it as a reason never to
> define a method in the singleton class. I'd say it's more that you
> want to know what the ramifications of each technique are, and then
> choose the one you want. In that sense it's analogous (though not
> identical) to the non-singleton case, where a method defined in a
> class "wins", for the instances of the class, over definitions in
> included modules. That can be good, or not; it depends on what you're
> trying to do.
>
> It all comes down to mastery of the order of method lookup, which then
> allows you to do pretty much any permutation.

Can you think of a good example of where it is NOT good? All I can think
of is when we need to metaprogram around someone else not using modules.

I'm sure there are occasions to act directly on the singleton, but I've
come to believe that should be the exception rather than the rule. And I
think it would behoove Ruby to promote that as the common idiom. We've
grown accustom to seeing "class << self". But I think it should be
raising flags instead --"we are doing something very metay here".

T.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-03 14:49
(Received via mailing list)
On Tue, 3 Feb 2009, Thomas Sawyer wrote:

>> class "wins", for the instances of the class, over definitions in
> come to believe that should be the exception rather than the rule. And I
> think it would behoove Ruby to promote that as the common idiom. We've
> grown accustom to seeing "class << self". But I think it should be
> raising flags instead --"we are doing something very metay here".

I disagree. I think that excessive meta-ness is to a large extent in
the eye of the beholder. The objects don't know that there's anything
"meta" about what they're being asked to do (resolve a message into a
method, by searching along their lookup path), and the class keyword
doesn't care whether you use the "<< obj" notation or the "MyClass"
notation.

Jay's example of extending an individual object twice is interesting,
but I don't think I've ever actually had to do it. And the only
problem is mixing the two techniques:

   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.


David

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

http://www.wishsight.com => Independent, social wishlist management!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-03 22:06
(Received via mailing list)
On Tue, Feb 3, 2009 at 2:44 PM, David A. Black <dblack@rubypal.com>
wrote:
>  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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-03 22:26
(Received via mailing list)
Hi --

On Wed, 4 Feb 2009, Robert Dober wrote:

>>    end
>
> 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.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
703fbc991fd63e0e1db54dca9ea31b53?d=identicon&s=25 Robert Dober (Guest)
on 2009-02-04 08:40
(Received via mailing list)
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
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-04 13:01
(Received via mailing list)
Hi --

On Wed, 4 Feb 2009, Robert Dober wrote:

> 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.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

http://www.wishsight.com => Independent, social wishlist management!
This topic is locked and can not be replied to.