# Singleton method on object via define\_method?

**URL:** <https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537>\
**Category:** ruby-talk\
**Created:** [11 September 2004 09:48 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537 "2004-09-11T09:48:07Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\
**Post date:** [14 September 2004 01:24 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/21 "2004-09-14T01:24:53Z")

</div>

In article \<Pine.LNX.4.44.0409130856080.26699-100000@wobblini\>,

> **···**
>
> David A. Black \<dblack@wobblini.net\> wrote:
> 
> > Hi --
> > 
> > On Mon, 13 Sep 2004, Robert Klemme wrote:
> > 
> > > Originally I was going to argue that "virtual" is inappropriate because it  
> > > was deceiving. While thinking about this issue it occurred to me that  
> > > "singleton classes" aka "virtual classes" share a property with C++'s  
> > > "virtual classes": you cannot instantiate objects from them.
> > 
> > Actually if C++ has virtual classes, I think that's all the more  
> > reason for Ruby not to call them that. Any such point of contact  
> > inevitably leads to misunderstanding and/or expectation (i.e., that  
> > Ruby will be like the other language).
> 
> I agree. There are already too many overloaded terms - isn't that why we  
> were trying to get away from using 'singleton' class?
> 
> Now I don't remember, but what was the problem with calling them  
> metaclasses?
> 
> Phil

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [14 September 2004 08:34 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/22 "2004-09-14T08:34:54Z")

</div>

"David A. Black" \<dblack@wobblini.net\> schrieb im Newsbeitrag  
news:Pine.LNX.4.44.0409130856080.26699-100000@wobblini...

> Hi --
> 
> \> Originally I was going to argue that "virtual" is inappropriate

because it

> \> was deceiving. While thinking about this issue it occurred to me that  
> \> "singleton classes" aka "virtual classes" share a property with C++'s  
> \> "virtual classes": you cannot instantiate objects from them.
> 
> Actually if C++ has virtual classes, I think that's all the more  
> reason for Ruby not to call them that. Any such point of contact  
> inevitably leads to misunderstanding and/or expectation (i.e., that  
> Ruby will be like the other language).
> 
> \> OTOH, you can have exactly one instance of this class, but this

instance

> \> preceedes the class (i.e. first the instance is created and then -

maybe -

> \> the class). Strictly speaking, the instance is the factory for the  
> \> class - not the other way round as it is normally.  
> \>  
> \> \<philosophical\>I depends on everyones notion of "class" whether he or

she

> \> thinks this no longer makes it a class. Although in that case I'd be  
> \> interested to learn a more appropriate name for this  
> \> thing.\</philosophical\>  
> \>  
> \> \> [I wrote:]  
> \> \>  
> \> \> the whole per-object  
> \> \> behavior model of Ruby is based on the idea that every object has

both

> \> \> a class of origin and a class of its own where the definitions  
> \> \> exclusive to that object reside. This isn't abnormal, nor an  
> \> \> aberration; it's the way the whole thing works.  
> \>  
> \> Well, it's normal in Ruby. But generally speaking the naive OO expert  
> \> would expect either not to have singleton/virtual classes (SVC :-))

\*or\*

> \> have Object#class return the singleton class - if that would exist.

Note,

> \> I'm not advocating to change this in any way - in fact it's good the

way

> \> it is. I just try to uncover why SVC often create confusion.
> 
> "Naive OO expert" -- interesting 🙂

Isn't it? 🙂

> "Normal in Ruby" is good enough  
> for me, since we're talking about Ruby. Otherwise it becomes an  
> argument that there's an immutable/official OO model that languages  
> must not deviate from. (I know you don't really think this -- I'm  
> just extrapolating from what you're saying.)

Well, yes, the extrapolation was correct. Although I couldn't agree more,  
that there is no such thing as a commonly agreed model of OO, I'd say  
singleton classes the way they are in Ruby are not part of it. 🙂

> \> The schizophrenic thing about SVC is, that instances change their

class at

> \> most once without showing it to the outside world (i.e. #class still  
> \> returns the original class).
> 
> I think we're looking at this backwards in this discussion. We're  
> looking at it as: Objects have this weird class-like thing, so what  
> is it? I think it's better to look at it from the other end, like  
> this: Objects in Ruby can have methods added to them on a per-object  
> basis. That's a fundamental principle of Ruby (whether it is true of  
> other OO languages or not). The way Matz has chosen to implement this  
> is by associating a second, dedicated class with each object. That's  
> what this class actually \*is\* -- it's the fulfillment of that design,  
> not something growing off the design that has to be explained  
> separately.

While that's certainly true, we're (I am) here trying to grasp the nature  
of these things to come up with a more appropriate name. At least that's  
my understanding of the thread.

> The details then fall into place. The fact that the class doesn't  
> exist until it's needn't does not have to mean that there's anything  
> virtual about it

.... but it might be a good reason to call it "virtual": it simply doesn't  
exist the whole time. 🙂 OTOH, you can't tell from the outside - it's  
there when you need it - lazyly initialized... ("lazy\_class"? Oh no...)

> -- it's just a matter of efficiency, and it's  
> transparent. And it's a perfectly real class, because it fits the  
> definition of what a class can be in Ruby.

.... apart from the instance creation.

> Hmmm... "dedicated\_class"... hmmm... 🙂

How about "instance\_class"?

Hmm...

&nbsp;&nbsp;&nbsp;&nbsp;robert

> **···**
>
> > On Mon, 13 Sep 2004, Robert Klemme wrote:

---

<div class="post-metadata">

**Author:** ![gabriele\_renzi](https://avatars.discourse-cdn.com/v4/letter/g/e19b73/32.png) [@gabriele\_renzi](https://rubytalk.org/u/gabriele_renzi)\
**Post date:** [13 September 2004 08:24 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/23 "2004-09-13T08:24:55Z")

</div>

Randy W. Sims ha scritto:

> Sounds sort of like a traits[1] or what Perl 6 refers to as roles[2][3]. But, then this is deeper Ruby than I'm familiar with.

I think traits mostly are what we call modules

---

<div class="post-metadata">

**Author:** ![T\_Onoma](https://avatars.discourse-cdn.com/v4/letter/t/c2a13f/32.png) [@T\_Onoma](https://rubytalk.org/u/T_Onoma)\
**Post date:** [14 September 2004 02:17 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/24 "2004-09-14T02:17:15Z")

</div>

Cause it is so meta-meaningless !?

What about something most meaningful, like per\_instance\_class or  
per\_object\_class. Albeit virtual\_class doesn't bother me as much. I don't C.

> **···**
>
> On Monday 13 September 2004 09:24 pm, Phil Tomson wrote:
> 
> > In article \<Pine.LNX.4.44.0409130856080.26699-100000@wobblini\>,
> > 
> > David A. Black \<dblack@wobblini.net\> wrote:  
> > \>Hi --  
> > \>  
> > \>On Mon, 13 Sep 2004, Robert Klemme wrote:  
> > \>\> Originally I was going to argue that "virtual" is inappropriate because  
> > \>\> it was deceiving. While thinking about this issue it occurred to me  
> > \>\> that "singleton classes" aka "virtual classes" share a property with  
> > \>\> C++'s "virtual classes": you cannot instantiate objects from them.  
> > \>  
> > \>Actually if C++ has virtual classes, I think that's all the more  
> > \>reason for Ruby not to call them that. Any such point of contact  
> > \>inevitably leads to misunderstanding and/or expectation (i.e., that  
> > \>Ruby will be like the other language).
> > 
> > I agree. There are already too many overloaded terms - isn't that why we  
> > were trying to get away from using 'singleton' class?
> > 
> > Now I don't remember, but what was the problem with calling them  
> > metaclasses?
> 
> --  
> ( o \_ カラチ  
> // trans.  
> / \ transami@runbox.com
> 
> I don't give a damn for a man that can only spell a word one way.  
> -Mark Twain

---

<div class="post-metadata">

**Author:** ![Mauricio\_Fernndez](https://avatars.discourse-cdn.com/v4/letter/m/e495f1/32.png) [@Mauricio\_Fernndez](https://rubytalk.org/u/Mauricio_Fernndez)\
**Post date:** [14 September 2004 09:53 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/25 "2004-09-14T09:53:11Z")

</div>

There's at least one case where you can know if the singleton class has  
been created or not (singletons of singletons). And you can always know  
if you're using evil.rb, of course 🙂

> **···**
>
> On Tue, Sep 14, 2004 at 05:34:54PM +0900, Robert Klemme wrote:
> 
> > .... but it might be a good reason to call it "virtual": it simply doesn't  
> > exist the whole time. 🙂 OTOH, you can't tell from the outside - it's  
> > there when you need it - lazyly initialized... ("lazy\_class"? Oh no...)
> 
> --  
> Running Debian GNU/Linux Sid (unstable)  
> batsman dot geo at yahoo dot com

---

<div class="post-metadata">

**Author:** ![gabriele\_renzi](https://avatars.discourse-cdn.com/v4/letter/g/e19b73/32.png) [@gabriele\_renzi](https://rubytalk.org/u/gabriele_renzi)\
**Post date:** [14 September 2004 10:05 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/26 "2004-09-14T10:05:09Z")

</div>

Phil Tomson ha scritto:

> I agree. There are already too many overloaded terms - isn't that why we were trying to get away from using 'singleton' class?
> 
> Now I don't remember, but what was the problem with calling them metaclasses?

metaclass already is used in other contexts in other languages, where it stands for the (redefineable) class of a class. In ruby we usually just override #new, in other languages they define their own class hierarchy, so this has the same problem that virtual.

---

<div class="post-metadata">

**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\
**Post date:** [14 September 2004 10:42 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/27 "2004-09-14T10:42:45Z")

</div>

Hi --

> \> [I wrote:]  
> \>  
> \> I think we're looking at this backwards in this discussion. We're  
> \> looking at it as: Objects have this weird class-like thing, so what  
> \> is it? I think it's better to look at it from the other end, like  
> \> this: Objects in Ruby can have methods added to them on a per-object  
> \> basis. That's a fundamental principle of Ruby (whether it is true of  
> \> other OO languages or not). The way Matz has chosen to implement this  
> \> is by associating a second, dedicated class with each object. That's  
> \> what this class actually \*is\* -- it's the fulfillment of that design,  
> \> not something growing off the design that has to be explained  
> \> separately.
> 
> While that's certainly true, we're (I am) here trying to grasp the nature  
> of these things to come up with a more appropriate name. At least that's  
> my understanding of the thread.

I agree, but I think the nature of singleton (or whatever) classes is  
that they serve to manifest an important design feature of Ruby.  
That being their nature, questions like whether they are identical to  
other classes, etc., are secondary, not primary.

> \> -- it's just a matter of efficiency, and it's  
> \> transparent. And it's a perfectly real class, because it fits the  
> \> definition of what a class can be in Ruby.
> 
> .... apart from the instance creation.

But that's the point: "being a class" in Ruby does not actually always  
mean being instantiable. We know this, because there are classes that  
aren't. To argue it the other way would be like saying: there are  
variables that begin with "@", so variables in Ruby begin with "@";  
therefore, "var" can't be a variable. (Don't worry -- I'm completely  
aware of what can be said both for and against this analogy 🙂 But  
I still think it's good to let the language talk to us, rather than  
the other way around.)

> \> Hmmm... "dedicated\_class"... hmmm... 🙂
> 
> How about "instance\_class"?

Interesting... though kind of weird that an object would be an  
instance of something other than its instance\_class 🙂

David

> **···**
>
> On Tue, 14 Sep 2004, Robert Klemme wrote:
> 
> --  
> David A. Black  
> dblack@wobblini.net

---

<div class="post-metadata">

**Author:** ![Randy\_W\_Sims](https://avatars.discourse-cdn.com/v4/letter/r/b487fb/32.png) [@Randy\_W\_Sims](https://rubytalk.org/u/Randy_W_Sims)\
**Post date:** [13 September 2004 16:55 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/28 "2004-09-13T16:55:59Z")

</div>

gabriele renzi wrote:

> Randy W. Sims ha scritto:
> 
> > Sounds sort of like a traits[1] or what Perl 6 refers to as roles[2][3]. But, then this is deeper Ruby than I'm familiar with.
> 
> I think traits mostly are what we call modules

I'm still learning Ruby, but aren't modules pretty much static? I think of traits as a set of behaviors that an object can take on at any point in it's lifetime. These behaviors are specific to that instance. They are transient behaviors that can be taken on and latter shed off. You would test for the presence of a trait before using it (much like testing is\_a?). etc.

Randy.

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [14 September 2004 10:39 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/29 "2004-09-14T10:39:57Z")

</div>

"Mauricio Fernández" \<batsman.geo@yahoo.com\> schrieb im Newsbeitrag  
news:20040914095258.GA6742@student.ei.uni-stuttgart.de...

> \> .... but it might be a good reason to call it "virtual": it simply

doesn't

> \> exist the whole time. 🙂 OTOH, you can't tell from the outside -

it's

> \> there when you need it - lazyly initialized... ("lazy\_class"? Oh

no...)

> There's at least one case where you can know if the singleton class has  
> been created or not (singletons of singletons).

How come? What's special about singletons here?

> And you can always know  
> if you're using evil.rb, of course 🙂

How exactly would you want to do it? I don't see how eval helps here.

The only way I can imagine is indirect: via instance\_methods. But that  
test can only assure, that the singleton class is created, you can't be  
sure as long as the difference is empty:

> > s=""

=\> ""

> > class \<\< s ; def length() 1 end; end

=\> nil

> > s.methods - s.class.instance\_methods

=\>

> > class \<\< s ; def foo;"foo"; end; end

=\> nil

> > s.methods - s.class.instance\_methods

=\> ["foo"]

Regards

&nbsp;&nbsp;&nbsp;&nbsp;robert

> **···**
>
> > On Tue, Sep 14, 2004 at 05:34:54PM +0900, Robert Klemme wrote:

---

<div class="post-metadata">

**Author:** ![David\_A\_Black3](https://avatars.discourse-cdn.com/v4/letter/d/6a8cbe/32.png) [@David\_A\_Black3](https://rubytalk.org/u/David_A_Black3)\
**Post date:** [14 September 2004 10:43 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/30 "2004-09-14T10:43:06Z")

</div>

Hi --

> \> .... but it might be a good reason to call it "virtual": it simply doesn't  
> \> exist the whole time. 🙂 OTOH, you can't tell from the outside - it's  
> \> there when you need it - lazyly initialized... ("lazy\_class"? Oh no...)
> 
> There's at least one case where you can know if the singleton class has  
> been created or not (singletons of singletons).

Can you elaborate and/or give an example of what you mean?

> And you can always know if you're using evil.rb, of course 🙂

Still holding out for a name change 🙂

David

> **···**
>
> On Tue, 14 Sep 2004, Mauricio Fernández wrote:
> 
> > On Tue, Sep 14, 2004 at 05:34:54PM +0900, Robert Klemme wrote:
> 
> --  
> David A. Black  
> dblack@wobblini.net

---

<div class="post-metadata">

**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\
**Post date:** [13 September 2004 19:09 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/31 "2004-09-13T19:09:55Z")

</div>

In article \<4145CFE2.7070404@thepierianspring.org\>,

> gabriele renzi wrote:
> 
> > Randy W. Sims ha scritto:
> > 
> > > Sounds sort of like a traits[1] or what Perl 6 refers to as  
> > > roles[2][3]. But, then this is deeper Ruby than I'm familiar with.
> > 
> > I think traits mostly are what we call modules
> 
> I'm still learning Ruby, but aren't modules pretty much static? I think  
> of traits as a set of behaviors that an object can take on at any point  
> in it's lifetime. These behaviors are specific to that instance. They  
> are transient behaviors that can be taken on and latter shed off. You  
> would test for the presence of a trait before using it (much like  
> testing is\_a?). etc.

You can always add more methods to a module as well as remove methods from  
a module:

irb(main):001:0\> module Foo  
irb(main):002:1\> def a  
irb(main):003:2\> "a"  
irb(main):004:2\> end  
irb(main):005:1\> def b  
irb(main):006:2\> "b"  
irb(main):007:2\> end  
irb(main):008:1\> end  
=\> nil  
irb(main):009:0\> class Bar  
irb(main):010:1\> include Foo  
irb(main):011:1\> end  
=\> Bar  
irb(main):012:0\> b = Bar.new  
=\> #\<Bar:0x400c3418\>  
irb(main):013:0\> b.a  
=\> "a"  
irb(main):014:0\> b.b  
=\> "b"  
irb(main):015:0\> module Foo  
irb(main):016:1\> undef b  
irb(main):017:1\> end  
irb(main):018:0\> b.b  
NoMethodError: undefined method `b' for #\<Bar:0x400c3418\>  
&nbsp;&nbsp;from (irb):18  
irb(main):019:0\>  
irb(main):019:0\> module Foo  
irb(main):020:1\> def c  
irb(main):021:2\> "c"  
irb(main):022:2\> end  
irb(main):023:1\> end  
=\> nil  
irb(main):024:0\> b.c  
=\> "c"

However, with traits & roles (and I'm certainly no expert) wouldn't it be  
better to have different modules that get mixed-in and 'unmixed'.

So you might have:

&nbsp;&nbsp;class Baz  
&nbsp;&nbsp;end

&nbsp;&nbsp;baz = Baz.new  
&nbsp;&nbsp;baz.extend Foo #baz now has Foo 'traits'

....and later you might want to do:  
&nbsp;&nbsp;baz.unextend Foo #remove the Foo 'traits' from baz

....later on you could add another set of traits to baz:  
&nbsp;&nbsp;baz.extend OtherTraits

Of course there is no 'unextend', but there are probably ways to  
implement this. For example, you could get a list of all of the methods  
of Foo and undef them in the baz object (couldn't you?)

Phil

> **···**
>
> Randy W. Sims \<ml-ruby@thepierianspring.org\> wrote:

---

<div class="post-metadata">

**Author:** ![Mauricio\_Fernndez](https://avatars.discourse-cdn.com/v4/letter/m/e495f1/32.png) [@Mauricio\_Fernndez](https://rubytalk.org/u/Mauricio_Fernndez)\
**Post date:** [14 September 2004 11:32 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/32 "2004-09-14T11:32:01Z")

</div>

> \> There's at least one case where you can know if the singleton class has  
> \> been created or not (singletons of singletons).
> 
> How come? What's special about singletons here?

> > o = Object.new

=\> #\<Object:0x401fdd20\>

> > class \<\< o; class \<\< self; def foo; "foo" end end end

=\> nil

> > class \<\< o; class \<\< self; foo end end

=\> "foo"

> > class \<\< o; class \<\< self; class \<\< self; end end end

=\> nil

> > class \<\< o; class \<\< self; foo end end

NameError: undefined local variable or method `foo' for #\<Class:#\<Class:#\<Object:0x401fdd20\>\>\>  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from (irb):5

> \> And you can always know  
> \> if you're using evil.rb, of course 🙂
> 
> How exactly would you want to do it? I don't see how eval helps here.

eval is evil, but I really meant evil.rb 🙂

> > require 'evil'

=\> true

> > o = Object.new

=\> #\<Object:0x4032e35c\>

> > o.internal.klass.to\_i

=\> 1075690784

> > class \<\< o; end

=\> nil

> > o.internal.klass.to\_i

=\> 1076982108

> > class \<\< o; def foo; end end

=\> nil

> > ObjectSpace.\_id2ref(o.internal.klass.to\_i/2).instance\_methods.include? "foo"

=\> true

> > klass = ObjectSpace.\_id2ref(o.internal.klass.to\_i/2)

=\> #\<Class:#\<Object:0x4032e35c\>\>

> > class \<\< o; self end

=\> #\<Class:#\<Object:0x4032e35c\>\>

hence

> > def has\_singleton?(obj); obj.class.id \* 2 != obj.internal.klass.to\_i end

=\> nil

> > o = ""

=\> ""

> > has\_singleton? o

=\> false

> > class \<\< o; end

=\> nil

> > has\_singleton? o

=\> true

> **···**
>
> On Tue, Sep 14, 2004 at 07:39:57PM +0900, Robert Klemme wrote:
> 
> --  
> Running Debian GNU/Linux Sid (unstable)  
> batsman dot geo at yahoo dot com

---

<div class="post-metadata">

**Author:** ![Mauricio\_Fernndez](https://avatars.discourse-cdn.com/v4/letter/m/e495f1/32.png) [@Mauricio\_Fernndez](https://rubytalk.org/u/Mauricio_Fernndez)\
**Post date:** [14 September 2004 11:40 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/33 "2004-09-14T11:40:52Z")

</div>

See my other response to Robert's post.  
The reason is in rb\_make\_metaclass:

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (BUILTIN\_TYPE(obj) == T\_CLASS && FL\_TEST(obj, FL\_SINGLETON)) {  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RBASIC(klass)-\>klass = klass;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RCLASS(klass)-\>super = RBASIC(rb\_class\_real(RCLASS(obj)-\>super))-\>klass;  
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}

> **···**
>
> On Tue, Sep 14, 2004 at 07:43:06PM +0900, David A. Black wrote:
> 
> > Hi --
> > 
> > On Tue, 14 Sep 2004, Mauricio Fernández wrote:
> > 
> > \> On Tue, Sep 14, 2004 at 05:34:54PM +0900, Robert Klemme wrote:  
> > \> \> .... but it might be a good reason to call it "virtual": it simply doesn't  
> > \> \> exist the whole time. 🙂 OTOH, you can't tell from the outside - it's  
> > \> \> there when you need it - lazyly initialized... ("lazy\_class"? Oh no...)  
> > \>  
> > \> There's at least one case where you can know if the singleton class has  
> > \> been created or not (singletons of singletons).
> > 
> > Can you elaborate and/or give an example of what you mean?
> 
> --  
> Running Debian GNU/Linux Sid (unstable)  
> batsman dot geo at yahoo dot com

---

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [13 September 2004 23:18 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/34 "2004-09-13T23:18:59Z")

</div>

Phil wrote:

> So you might have:
> 
> &nbsp;&nbsp;class Baz  
> &nbsp;&nbsp;end
> 
> &nbsp;&nbsp;baz = Baz.new  
> &nbsp;&nbsp;baz.extend Foo #baz now has Foo 'traits'
> 
> ....and later you might want to do:  
> &nbsp;&nbsp;baz.unextend Foo #remove the Foo 'traits' from baz
> 
> ....later on you could add another set of traits to baz:  
> &nbsp;&nbsp;baz.extend OtherTraits
> 
> Of course there is no 'unextend', but there are probably ways to  
> implement this. For example, you could get a list of all of the methods  
> of Foo and undef them in the baz object (couldn't you?)

I'd expect a proper implementation of 'unextend' to just "peel away a  
layer of methods", not actually remove them. So...

&nbsp;&nbsp;module Foo1  
&nbsp;&nbsp;&nbsp;&nbsp;def foo; "foo1"; end  
&nbsp;&nbsp;end

&nbsp;&nbsp;module Foo2  
&nbsp;&nbsp;&nbsp;&nbsp;def foo; "foo2"; end  
&nbsp;&nbsp;end

&nbsp;&nbsp;class X  
&nbsp;&nbsp;end

&nbsp;&nbsp;x = X.new

&nbsp;&nbsp;x.foo # error

&nbsp;&nbsp;x.extend Foo1  
&nbsp;&nbsp;x.foo # "foo1"

&nbsp;&nbsp;x.extend Foo2  
&nbsp;&nbsp;x.foo # "foo2"

&nbsp;&nbsp;x.unextend Foo2  
&nbsp;&nbsp;x.foo # "foo1"

Gavin

---

<div class="post-metadata">

**Author:** ![Daniel\_Berger3](https://avatars.discourse-cdn.com/v4/letter/d/c68b51/32.png) [@Daniel\_Berger3](https://rubytalk.org/u/Daniel_Berger3)\
**Post date:** [14 September 2004 04:25 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/35 "2004-09-14T04:25:21Z")

</div>

ptkwt@aracnet.com (Phil Tomson) wrote in message news:\<ci4p8602fvt@enews4.newsguy.com\>...

> In article \<4145CFE2.7070404@thepierianspring.org\>,  
> \>gabriele renzi wrote:  
> \>\> Randy W. Sims ha scritto:  
> \>\>  
> \>\>\> Sounds sort of like a traits[1] or what Perl 6 refers to as  
> \>\>\> roles[2][3]. But, then this is deeper Ruby than I'm familiar with.  
> \>\>  
> \>\>  
> \>\> I think traits mostly are what we call modules

Take a look at this blog/article from David Naseby where he implements  
traits in Ruby:

[http://homepages.ihug.com.au/~naseby/33.html](http://homepages.ihug.com.au/~naseby/33.html)

Regards,

Dan

> **···**
>
> > Randy W. Sims \<ml-ruby@thepierianspring.org\> wrote:

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [15 September 2004 08:09 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/36 "2004-09-15T08:09:52Z")

</div>

"Mauricio Fernández" \<batsman.geo@yahoo.com\> schrieb im Newsbeitrag  
news:20040914113158.GA12061@student.ei.uni-stuttgart.de...

> \> \> There's at least one case where you can know if the singleton class

has

> \> \> been created or not (singletons of singletons).  
> \>  
> \> How come? What's special about singletons here?
> 
> \>\> o = Object.new  
> =\> #\<Object:0x401fdd20\>  
> \>\> class \<\< o; class \<\< self; def foo; "foo" end end end  
> =\> nil  
> \>\> class \<\< o; class \<\< self; foo end end  
> =\> "foo"  
> \>\> class \<\< o; class \<\< self; class \<\< self; end end end  
> =\> nil  
> \>\> class \<\< o; class \<\< self; foo end end  
> NameError: undefined local variable or method `foo' for

#\<Class:#\<Class:#\<Object:0x401fdd20\>\>\>

> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from (irb):5

Hm, but what about:

> > o = Object.new

=\> #\<Object:0x10184d40\>

> > class \<\< o; class \<\< self; def to\_s ; "foo" end end end

=\> nil

> > class \<\< o; class \<\< self;to\_s end end

=\> "foo"

> > class \<\< o; class \<\< self; class \<\< self; end end end

=\> nil

> > class \<\< o; class \<\< self; to\_s end end

=\> "#\<Class:foo\>"

> \> \> And you can always know  
> \> \> if you're using evil.rb, of course 🙂  
> \>  
> \> How exactly would you want to do it? I don't see how eval helps here.
> 
> eval is evil, but I really meant evil.rb 🙂

Oops. I wasn't aware of evil.rb and assumed an evil pun. 🙂 Shame on  
me...

> \>\> require 'evil'  
> =\> true  
> \>\> o = Object.new  
> =\> #\<Object:0x4032e35c\>  
> \>\> o.internal.klass.to\_i  
> =\> 1075690784  
> \>\> class \<\< o; end  
> =\> nil  
> \>\> o.internal.klass.to\_i  
> =\> 1076982108  
> \>\> class \<\< o; def foo; end end  
> =\> nil  
> \>\>

ObjectSpace.\_id2ref(o.internal.klass.to\_i/2).instance\_methods.include?  
"foo"

> =\> true  
> \>\> klass = ObjectSpace.\_id2ref(o.internal.klass.to\_i/2)  
> =\> #\<Class:#\<Object:0x4032e35c\>\>  
> \>\> class \<\< o; self end  
> =\> #\<Class:#\<Object:0x4032e35c\>\>
> 
> hence
> 
> \>\> def has\_singleton?(obj); obj.class.id \* 2 != obj.internal.klass.to\_i

end

> =\> nil  
> \>\> o = ""  
> =\> ""  
> \>\> has\_singleton? o  
> =\> false  
> \>\> class \<\< o; end  
> =\> nil  
> \>\> has\_singleton? o  
> =\> true

Hm, well ok. But is there an equivalent without evil.rb, i.e. with  
"normal" Ruby code? I know that you can access all kinds of internals if  
you write an extension, but AFAIK you can't know whether there is a  
singleton class or not. Please correct me if I'm wrong here...

Kind regards

&nbsp;&nbsp;&nbsp;&nbsp;robert

> **···**
>
> > On Tue, Sep 14, 2004 at 07:39:57PM +0900, Robert Klemme wrote:

---

<div class="post-metadata">

**Author:** ![Ptkwt](https://avatars.discourse-cdn.com/v4/letter/p/f14d63/32.png) [@Ptkwt](https://rubytalk.org/u/Ptkwt)\
**Post date:** [14 September 2004 01:09 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/37 "2004-09-14T01:09:54Z")

</div>

In article \<4581.218.214.1.200.1095117526.squirrel@webmail.imagineis.com\>,

> **···**
>
> Gavin Sinclair \<gsinclair@soyabean.com.au\> wrote:
> 
> > Phil wrote:
> > 
> > > So you might have:
> > > 
> > > &nbsp;&nbsp;class Baz  
> > > &nbsp;&nbsp;end
> > > 
> > > &nbsp;&nbsp;baz = Baz.new  
> > > &nbsp;&nbsp;baz.extend Foo #baz now has Foo 'traits'
> > > 
> > > ....and later you might want to do:  
> > > &nbsp;&nbsp;baz.unextend Foo #remove the Foo 'traits' from baz
> > > 
> > > ....later on you could add another set of traits to baz:  
> > > &nbsp;&nbsp;baz.extend OtherTraits
> > > 
> > > Of course there is no 'unextend', but there are probably ways to  
> > > implement this. For example, you could get a list of all of the methods  
> > > of Foo and undef them in the baz object (couldn't you?)
> > 
> > I'd expect a proper implementation of 'unextend' to just "peel away a  
> > layer of methods", not actually remove them. So...
> > 
> > module Foo1  
> > &nbsp;&nbsp;&nbsp;def foo; "foo1"; end  
> > end
> > 
> > module Foo2  
> > &nbsp;&nbsp;&nbsp;def foo; "foo2"; end  
> > end
> > 
> > class X  
> > end
> > 
> > x = X.new
> > 
> > x.foo # error
> > 
> > x.extend Foo1  
> > x.foo # "foo1"
> > 
> > x.extend Foo2  
> > x.foo # "foo2"
> > 
> > x.unextend Foo2  
> > x.foo # "foo1"
> 
> Yes, you're right. This would be better behavior. Any idea how something  
> like that could be implemented?
> 
> Phil

---

<div class="post-metadata">

**Author:** ![Mauricio\_Fernndez](https://avatars.discourse-cdn.com/v4/letter/m/e495f1/32.png) [@Mauricio\_Fernndez](https://rubytalk.org/u/Mauricio_Fernndez)\
**Post date:** [15 September 2004 11:23 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/38 "2004-09-15T11:23:00Z")

</div>

> \>\> o = Object.new  
> =\> #\<Object:0x10184d40\>  
> \>\> class \<\< o; class \<\< self; def to\_s ; "foo" end end end  
> =\> nil  
> \>\> class \<\< o; class \<\< self;to\_s end end  
> =\> "foo"  
> \>\> class \<\< o; class \<\< self; class \<\< self; end end end  
> =\> nil  
> \>\> class \<\< o; class \<\< self; to\_s end end  
> =\> "#\<Class:foo\>"

It's using Module#to\_s because the klass of the singleton class is  
no longer itself... Module#to\_s ends up calling  
class \<\< o; self.to\_s end  
which you defined before.

> Hm, well ok. But is there an equivalent without evil.rb, i.e. with  
> "normal" Ruby code? I know that you can access all kinds of internals if  
> you write an extension, but AFAIK you can't know whether there is a  
> singleton class or not.

(I assume your last sentence if missing "... without an extension".)

The case above (singletons of singletons) is the only one I can think  
of right now where you can always know if the singleton has been created  
or not.

> **···**
>
> On Wed, Sep 15, 2004 at 05:09:52PM +0900, Robert Klemme wrote:
> 
> --  
> Running Debian GNU/Linux Sid (unstable)  
> batsman dot geo at yahoo dot com

---

<div class="post-metadata">

**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\
**Post date:** [14 September 2004 01:15 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/39 "2004-09-14T01:15:23Z")

</div>

Phil wrote:

> > module Foo1  
> > &nbsp;&nbsp;&nbsp;def foo; "foo1"; end  
> > end
> > 
> > module Foo2  
> > &nbsp;&nbsp;&nbsp;def foo; "foo2"; end  
> > end
> > 
> > class X  
> > end
> > 
> > x = X.new
> > 
> > x.foo # error
> > 
> > x.extend Foo1  
> > x.foo # "foo1"
> > 
> > x.extend Foo2  
> > x.foo # "foo2"
> > 
> > x.unextend Foo2  
> > x.foo # "foo1"
> 
> Yes, you're right. This would be better behavior. Any idea how  
> something like that could be implemented?

Yep: in the Ruby core! 🙂

Only pure-Ruby solution I can think of is to remember the modules that  
have been mixed in, and selectively reapply earlier ones when 'unextend'  
is called. Pretty fugly.

Gavin

---

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\
**Post date:** [15 September 2004 12:49 UTC](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537/40 "2004-09-15T12:49:50Z")

</div>

"Mauricio Fernández" \<batsman.geo@yahoo.com\> schrieb im Newsbeitrag  
news:20040915112257.GA14360@student.ei.uni-stuttgart.de...

> \> \>\> o = Object.new  
> \> =\> #\<Object:0x10184d40\>  
> \> \>\> class \<\< o; class \<\< self; def to\_s ; "foo" end end end  
> \> =\> nil  
> \> \>\> class \<\< o; class \<\< self;to\_s end end  
> \> =\> "foo"  
> \> \>\> class \<\< o; class \<\< self; class \<\< self; end end end  
> \> =\> nil  
> \> \>\> class \<\< o; class \<\< self; to\_s end end  
> \> =\> "#\<Class:foo\>"
> 
> It's using Module#to\_s because the klass of the singleton class is  
> no longer itself... Module#to\_s ends up calling  
> class \<\< o; self.to\_s end  
> which you defined before.

Well yes, but the fact remains that there is a singleton we don't know of,  
do we? Probably I don't see clearly your point so I'd appreciate it if  
you'd elaborate it.

> \> Hm, well ok. But is there an equivalent without evil.rb, i.e. with  
> \> "normal" Ruby code? I know that you can access all kinds of internals

if

> \> you write an extension, but AFAIK you can't know whether there is a  
> \> singleton class or not.
> 
> (I assume your last sentence if missing "... without an extension".)

You can safely assume this without altering the indended semantics of the  
sentence. 🙂

> The case above (singletons of singletons) is the only one I can think  
> of right now where you can always know if the singleton has been created  
> or not.

see above.

Kind regards

&nbsp;&nbsp;&nbsp;&nbsp;robert

> **···**
>
> > On Wed, Sep 15, 2004 at 05:09:52PM +0900, Robert Klemme wrote:

[Previous page](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537.md?page=1)

[Next page](https://rubytalk.org/t/singleton-method-on-object-via-define-method/13537.md?page=3)