Does singleton variables have any meaning?

Hello,

I would like to have a confirmation about the fact that singleton
variables just don’t have any meaning, or an explation about how to use
them.
An example to be sure that we are talking about the same thing :

class A

@class_instance_variable

class << self #or class << A

@singleton_variable # <- Can this be used/called elsewhere ?

def some_method
  @class_instance_variable
end

end

end

Thanks

Arno J. wrote:

end

Thanks
class A
class << self
@singleton_variable
attr_accessor :singleton_variable # <----- N.B.
end
end
irb(main):035:0> A.singleton_variable = :foo
=> :foo
irb(main):037:0> A.singleton_variable
=> :foo

That’s how I use them…

On Aug 16, 10:25 am, Alex Y. [email protected] wrote:

Arno J. wrote:

class A
@class_instance_variable
class << self #or class << A
@singleton_variable # <- Can this be used/called elsewhere ?
def some_method
@class_instance_variable
end
end
end

class A
class << self
@singleton_variable
attr_accessor :singleton_variable # <----- N.B.
end
end
irb(main):035:0> A.singleton_variable = :foo
=> :foo
irb(main):037:0> A.singleton_variable
=> :foo

Your accessor method there is referencing a new class-level instance
variable, that is in a different scope than your (no-op)
@singleton_variable line there.

irb(main):001:0> class A
irb(main):002:1> @foo = 1
irb(main):003:1> class << self
irb(main):004:2> @foo = 2
irb(main):005:2> attr_accessor :foo
irb(main):006:2> end
irb(main):007:1> end
=> nil
irb(main):008:0> A.foo
=> 1

Hi –

On Fri, 17 Aug 2007, Arno J. wrote:

class << self #or class << A

@singleton_variable # <- Can this be used/called elsewhere ?

Like all instance variables, it belongs to whatever object is ‘self’
at the point where the instance variable appears, and multiple
references to the same instance variable in different contexts where
self is the same, will be references to the same instance variable.

def some_method
@class_instance_variable
end

end

end

I don’t find the term “singleton variable” very helpful. All the
variables in your example are just instance variables. Calling them
“class instance variables” is sometimes useful, since there are
contexts in which it might sound like you mean an instance variable in
a class’s instance methods. But I’d be conservative about coining new
terms for instance variables that happen to occur in different
contexts.

David

Phrogz wrote:

end
irb(main):037:0> A.singleton_variable
irb(main):005:2> attr_accessor :foo
irb(main):006:2> end
irb(main):007:1> end
=> nil
irb(main):008:0> A.foo
=> 1

You’re absolutely right. Got myself confused in a maze of twisty
passages. Sorry for the noise :slight_smile:

class << self #or class << A

@singleton_variable # <- Can this be used/called elsewhere ?

Like all instance variables, it belongs to whatever object is ‘self’
at the point where the instance variable appears, and multiple
references to the same instance variable in different contexts where
self is the same, will be references to the same instance variable.

But here self is #Class:A. Here it really the same context/self as for
class instance variables (A).

I don’t find the term “singleton variable” very helpful. All the
variables in your example are just instance variables. Calling them
“class instance variables” is sometimes useful, since there are

So, let’s take an another example. After every “puts self” I put the
result.

class A
puts “Inside class”
puts self # A -> This is the self that our instance variable would be
linked to, making a “class instance variable”

def meth
puts “Inside method”
puts self # #<A:0x2ebd140>
end

def self.methc
puts “Inside class method”
puts self # A
end

class << self
puts “Inside singleton”
puts self # #Class:A -> and this is the self that our instance
variable would be linked to…

def meths
  puts "Inside singleton method"
  puts self # A
end

end
end

a = A.new
#<A:0x2ebd140>

With a being #<A:0x2ebd140>, the results are :

So, when defining what’s usually called a “class instance variable”, the
self is “A”. For what I call a “singleton variable”, but that you called
a “class instance variable”, the self is “#Class:A”.
To me, there’s a difference, but I don’t know what that “#Class:A” is.

It’s the same thing with a self.method.
Can someone tell me how to use those @my_variable and self.method in the
following class :

class A
class << self
@my_variable
def self.my_method
end
end

This is where I’d like to use it

end

Or we can use it from here on a new instance or an the class itself

maybe ?

I’ll sleep over it…

unknown wrote:

self is #Class:A (the singleton class of A), so @singleton_variable
belongs to #Class:A. It has no connection to A.

Ok, that’s what I guessed

#Class:A is the singleton class (sometimes called the “metaclass”)
of A. It’s a separate object; it has its own instance variables, and
doesn’t share them with A.

As for the terminology; here:
@var is an instance variable, and self is a class. So we can call it
an instance variable or a class instance variable. I don’t think it’s
a good idea to introduce yet another term (singleton variable) for it;
it just gets too confusing.

I’m sorry but I still don’t get it (maybe I’m a little bit nit_picking
also)

class A
@first_instance_var # self = A

def meth
@second_instance_var # self = #<A:0x2ebd140>
end

class << self
@thir_instance_var # self = #Class:A
end

end

All three variables are instance variables (just because of the @, as
far as I know).
BUT, for what I’ve read on the web / in books
first_… would be called a “class instance variable”
second_… would be called an “instance variable”
third_… would not be called (I never met any), or would be called a
“class instance variable” according to you, although self is not a class
but a singleton class.

I agree that since a singleton class is some sort of class, it can be
called a “class instance variable”. But my question are “how do I access
it ?” and “Is it any usefull” (I understand why first and second can be
used, but not third).

You could get indirect access to it if the object that owns it creates
wrapper methods for it. But if you put @my_variable where your “This”
comment is, it will be a completely different @my_variable.

I don’t want to put @my_variable here, I want to use the wrapper method
you’re talking about, but I don’t know how to build it :slight_smile:

David

Thank you for your time

Arno

I have no actual use case and I believe there will be not many save
for metaprogramming, meta-meta programming maybe :wink:

517/18 > cat singvar.rb && ruby singvar.rb
class A
@a = 42
class << self
@a = 222
def class_inst; @a end
def sing_inst; class << self; self end.instance_variable_get("@a")
end
end
end
puts A.class_inst
puts A.sing_inst
42
222

Cheers
Robert

On 8/17/07, Robert D. [email protected] wrote:

def sing_inst; class << self; self end.instance_variable_get("@a") end

I tend to think too complicated :frowning:

def sing_inst; class << self; @a end end

does the job of course.

42
222

R.

Hi –

On Fri, 17 Aug 2007, Arno J. wrote:

class instance variables (A).
self is #Class:A (the singleton class of A), so @singleton_variable
belongs to #Class:A. It has no connection to A.

puts “Inside class”
puts self # A
end

So, when defining what’s usually called a “class instance variable”, the
self is “A”. For what I call a “singleton variable”, but that you called
a “class instance variable”, the self is “#Class:A”.
To me, there’s a difference, but I don’t know what that “#Class:A” is.

#Class:A is the singleton class (sometimes called the “metaclass”)
of A. It’s a separate object; it has its own instance variables, and
doesn’t share them with A.

As for the terminology; here:

class << A
@var
end

@var is an instance variable, and self is a class. So we can call it
an instance variable or a class instance variable. I don’t think it’s
a good idea to introduce yet another term (singleton variable) for it;
it just gets too confusing.

This is where I’d like to use it

end

You can’t use it there, because you’re in a new ‘self’ context (A
rather than #Class:A). Therefore the instance variables belong to a
different object.

You could get indirect access to it if the object that owns it creates
wrapper methods for it. But if you put @my_variable where your “This”
comment is, it will be a completely different @my_variable.

David

Hi –

On Fri, 17 Aug 2007, Arno J. wrote:

@first_instance_var # self = A

All three variables are instance variables (just because of the @, as
far as I know).
BUT, for what I’ve read on the web / in books
first_… would be called a “class instance variable”
second_… would be called an “instance variable”
third_… would not be called (I never met any), or would be called a
“class instance variable” according to you, although self is not a class
but a singleton class.

Singleton classes are classes. More importantly, though, it’s best to
keep the terminology as simple as possible.

All of these things are instance variables. The only reason to use a
longer name is to make it clear in usage where someone might not know
what you mean. If you’ve got an instance variable of #Class:A, you
will almost certain describe as “an instance variable of the singleton
class of the class A”, or something like that. There’s almost
certainly no need to create a separate term for it.

Mind you, I don’t think I’ve ever seen such an instance variable, so
it’s probably not a big problem :slight_smile:

you’re talking about, but I don’t know how to build it :slight_smile:
You can always write a wrapper like this:

def self.x
@x
end

or you can write an x method in the class or singleton class of x.
Similarly for x= (the setter method).

You can also use the attr_* family of methods to create the wrapper
method(s) for you.

To do that in your example, you’d do:

class A
class << self
class << self
attr_accessor :x
end
end
end

But you’ll never see this much nesting! :slight_smile: A more common case might
be:

class A
end

a = A.new

class << a
attr_accessor :x
end

which creates attribute get/set methods for ‘x’ on the object a.

David

unknown wrote:

Singleton classes are classes.

Yes, I was just trying to make a slight difference, just like we don’t
say “variables” but “instance variables”, while both are variables :slight_smile:

All of these things are instance variables. The only reason to use a
longer name is to make it clear in usage where someone might not know
what you mean. If you’ve got an instance variable of #Class:A, you
will almost certain describe as “an instance variable of the singleton
class of the class A”, or something like that. There’s almost
certainly no need to create a separate term for it.

I couldn’t agree more ! You even almost quoted me (I said “All three
variables are instance variables”).
And I also agree about your “longer name” explanation 100% : I invented
the term “singleton variable”, but I thought it would be as clear as
your “instance variable of the singleton class of the class A”, but
obviously I was wrong :slight_smile:

Mind you, I don’t think I’ve ever seen such an instance variable, so
it’s probably not a big problem :slight_smile:

Hehe, ok. Since I’m new to Ruby, I couldn’t find out if it had any use
or not.

You can also use the attr_* family of methods to create the wrapper
method(s) for you.

To do that in your example, you’d do:

class A
class << self
class << self
attr_accessor :x
end
end
end

OK !

Many thanks :slight_smile:

Hi –

On Fri, 17 Aug 2007, Arno J. wrote:

class of the class A", or something like that. There’s almost
certainly no need to create a separate term for it.

I couldn’t agree more ! You even almost quoted me (I said “All three
variables are instance variables”).
And I also agree about your “longer name” explanation 100% : I invented
the term “singleton variable”, but I thought it would be as clear as
your “instance variable of the singleton class of the class A”, but
obviously I was wrong :slight_smile:

Luckily these particular instance variables almost never occur so
there’s probably not too much at stake either way :slight_smile:

David

On Aug 17, 2007, at 4:10 PM, Todd B. wrote:

their own thing to do :slight_smile:
Can anyone explain whether there’s a direct relationship between the
“singleton” in “singleton pattern” and the “singleton” in “singleton
class”? I mean, does the singleton class implement the singleton
pattern somehow (I am not aware of any instance of the singleton
class) and hence the name? Or is “singleton” there used just because
of the meaning it conveys to the class, so to speak, and not because
of the pattern?

– fxn

On Aug 17, 8:22 am, Xavier N. [email protected] wrote:

Can anyone explain whether there’s a direct relationship between the
“singleton” in “singleton pattern” and the “singleton” in “singleton
class”?

There is not. It’s an unfortunate name collision that can confuse
those new to the language and terminology. (It certainly confused me
for a while.) If you search the archives, you will see a LOT of
discussion over renaming “singleton class” to something else.

I even started a page on the RubyGarden wiki to help collect and
discuss the various proposals, but that seems not to be working now.

http://rubygarden.org:3000/Ruby/page/show/RenamingSingletonClass

On 8/17/07, Arno J. [email protected] wrote:

unknown wrote:

Singleton classes are classes.

Yes, I was just trying to make a slight difference, just like we don’t
say “variables” but “instance variables”, while both are variables :slight_smile:

The idea of singletons is to allow to add (or subtract) functionality
to single objects. Little happy people floating around with each
their own thing to do :slight_smile:

Listen (with earnest) to David.

Todd

Hi –

On Sat, 18 Aug 2007, Phrogz wrote:

I even started a page on the RubyGarden wiki to help collect and
discuss the various proposals, but that seems not to be working now.

http://rubygarden.org:3000/Ruby/page/show/RenamingSingletonClass

You can get there now:

http://rubygarden.org/Ruby/page/show/RenamingSingletonClass

Or just peruse /usr/share/dict/words :slight_smile:

David

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs