Object#singleton_class in Ruby 1.9?

[Forum]

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

···

On Sat, Jan 31, 2009 at 9:13 PM, David A. Black <dblack@rubypal.com> wrote:

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

[Sean_O_Halpin]

[snip]

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

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

···

On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> wrote:

[Suraj_Kurapati1 (Suraj Kurapati)]

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.

···

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

[Jesus_Gabriel_y_Gala (Jesús Gabriel y Galán)]

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

Jesus.

···

On Fri, Jan 30, 2009 at 5:46 PM, Gary Wright <gwtmp01@mac.com> wrote:

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.

[David_A_Black1 (David A. Black)]

Hi --

···

On Sun, 1 Feb 2009, Suraj Kurapati wrote:

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

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!

[David_A_Black1 (David A. Black)]

Hi --

[snip]

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

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.

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

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

···

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

On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> wrote:

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

[Forum]

[snip]

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

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

···

On Sun, Feb 1, 2009 at 9:02 AM, Sean O'Halpin <sean.ohalpin@gmail.com> wrote:

On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> wrote:

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

[7rans]

Sean O'halpin 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.

···

On Sat, Jan 31, 2009 at 8:03 PM, Thomas Sawyer <transfire@gmail.com> > wrote:

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

[7rans]

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.

···

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

[7rans]

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.
--
Posted via http://www.ruby-forum.com/\.

[Sean_O_Halpin]

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

···

On Sun, Feb 1, 2009 at 12:03 PM, David A. Black <dblack@rubypal.com> wrote:

[7rans]

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.

···

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

[Suraj_Kurapati1 (Suraj Kurapati)]

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.

···

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

[Jesus_Gabriel_y_Gala (Jesús Gabriel y Galán)]

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

···

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.

[David_A_Black1 (David A. Black)]

Hi --

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.

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

···

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

On Sun, Feb 1, 2009 at 12:03 PM, David A. Black <dblack@rubypal.com> wrote:

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

[David_A_Black1 (David A. Black)]

Hi --

···

On Mon, 2 Feb 2009, Thomas Sawyer wrote:

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.

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!

[Forum]

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.

···

On Mon, Feb 2, 2009 at 3:33 AM, Thomas Sawyer <transfire@gmail.com> wrote:
--
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

[Sean_O_Halpin]

[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

···

On Sun, Feb 1, 2009 at 7:42 PM, David A. Black <dblack@rubypal.com> wrote:

[7rans]

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!

Ruby: Underuse of Modules

Extend modules instead of defining methods on a metaclass

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

T.

···

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

[David_A_Black1 (David A. Black)]

Hi --

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

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.

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

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.

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

···

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:

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