On Thu, 24 Aug 2006, James Edward G. II wrote:
On Aug 23, 2006, at 3:13 PM, [email protected] wrote:
Sigh – Matz, please can we have this?
def singleton_class
class << self; self; end
end
much better, imho, and used all over my own code is
def singleton_class &b
sc = class << self; self; end
b ? sc.module_eval &b : sc
end
obj = Object.new
obj.singleton_class{ def foo() 42 end }
2 cts.
-a
On 8/23/06, [email protected] [email protected] wrote:
On Thu, 24 Aug 2006, James Edward G. II wrote:
On Aug 23, 2006, at 3:13 PM, [email protected] wrote:
Sigh – Matz, please can we have this?
def singleton_class
class << self; self; end
end
+100 - please give us singleton_class!
much better, imho, and used all over my own code is
def singleton_class &b
sc = class << self; self; end
b ? sc.module_eval &b : sc
endobj = Object.new
+1 to this implementation.
Hi –
On Thu, 24 Aug 2006, Nathan S. wrote:
$ irb
irb(main):010:2> endhoo won’t work.
Exactly! That’s the point I was getting at. It’d be nice if this would
work. “self” points to the object who’s method the interpreter is in, so
playing by that same game, “super” should point to the superclass of the
object who’s method the interpreter is in.
It depends what you mean by “should” I think the current behavior
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.
David
On Thu, 24 Aug 2006 [email protected] wrote:
On Thu, 24 Aug 2006, Douglas A. Seifert wrote:
irb(main):006:0>
=> nil
end
It depends what you mean by “should”
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.
If I’m thinking correctly, self.class.superclass will point to the
metaclass of the superclass of self. This isn’t what is wanted when
calling super.someMethod (that would be like doing
super.class.someMethod, which is different). I recognize Ruby is
different
from other langauges, but many other languages (even less OO capable
languages such as Java and C++) have the use of the “super.someMethod”
functionality.
Nate
Hi –
On Thu, 24 Aug 2006, Nathan S. wrote:
On Thu, 24 Aug 2006, Nathan S. wrote:
irb(main):005:1> end
irb(main):014:0> c.hoo
def zoo
object who’s method the interpreter is in.It depends what you mean by “should”
of super (looking for the next same-named method in a higher module or
class) is very useful, and should not be eliminated. So if a keyword
is introduced to be a synonym for self.class.superclass, it should
probably be something else.If I’m thinking correctly, self.class.superclass will point to the
metaclass of the superclass of self.
No; it will point to the superclass of the class of self
class C
end
class D < C
end
D.new.class.superclass # C
This isn’t what is wanted when calling super.someMethod (that would
be like doing super.class.someMethod, which is different). I
recognize Ruby is different from other langauges, but many other
languages (even less OO capable languages such as Java and C++) have
the use of the “super.someMethod” functionality.
Well… it’s probably good that Ruby isn’t a superset of those less OO
capable languages But I’m getting confused by the use of an
existing keyword to describe a new concept. Also, it’s not clear what
the keyword would actually produce. You’re sending the someMethod
message to it, but from what I understand you don’t really mean it to
respond to that method, but rather to re-send the message to the
current self, using the constraint that the currently visible version
of the method be skipped.
I wondering whether perhaps something other than message-sending
semantics would be better, since that’s an awful lot to hide behind
the dot. Maybe a block-wise evaluation of some kind?
David
On 23-aug-2006, at 18:43, William C. wrote:
Douglas A. Seifert wrote:
Why would you need to explicitly reference super? It is not
necessary:He has redefined the ‘another’ method in the child class. But for
some
reason, he needs the ‘another’ method in the parent class instead.
I am not saying I need to do that, I was curious if it’s at all
possible. It is in PHP for instance (in Python too AFAIK).
Sigh – Matz, please can we have this?
def singleton_class
class << self; self; end
end+100 - please give us singleton_class!
I concur as well and have been using this myself.
much better, imho, and used all over my own code is
def singleton_class &b
sc = class << self; self; end
b ? sc.module_eval &b : sc
endobj = Object.new
+1 to this implementation.
or the alternative:
def singleton_eval &b
singleton_class.module_eval &b
end
Farrel L. wrote:
end
That’s what I was looking for, altough it’s a strange use of the super
keyword.
(James Edward G. II: you were right about the Child < Parent part, I
forgot to include it in my example.)
Another question: I am a bit confused by other responses in this thread.
Say
I use the following code:
class Parent
def somemethod
end
def overrideme(param)
end
end
class Child < Parent
def overrideme(param)
# do stuff
super(param)
somemethod
end
end
The somemethod call in Child#overrideme works. Some posts in this thread
seem to say this impossible?
Bart (still learning ruby and starting to love it!)
“M” == Morton G. [email protected] writes:
M> A more correct conclusion would have been that Ruby’s ‘super’ should
M> be regarded more as a method call rather than as a pseudo-variable
yes, super can be seen as a method call.
–
Guy Decoux
“N” == Nathan S. [email protected] writes:
N> Therefore, in B#hi, self.class.superclass does not refer to the
superclass
N> of B – rather it refers to the metaclass of the super of B. If it
pointed
no, not really. self.class.superclass make reference to the superclass
of
B
N> to the superclass of B, then calling
N> self.class.superclass.hi
N> would print “hi”, instead of “A.hi”
no, if self.class.superclass == A then self.class.superclass.hi is the
same than A.hi, and ruby will print “A.hi”
Guy Decoux
Hello,
On Thu, 24 Aug 2006 [email protected] wrote:
No; it will point to the superclass of the class of self
class C
end
class D < C
end
D.new.class.superclass # C
I think we are using different terminology. Take a look at this code:
class A
def A.hi
puts “A.hi”
end
def hi
puts “hi”
end
end
class B < A
def hi
self.class.superclass.hi
end
end
b = B.new
b.hi
This will output
A.hi
In “Programming Ruby”, they define the “metaclass” as the object which
contains the class-wide objects of the class. IE, the metaclass of A
would
contain A.hi, and not A#hi (I could be getting the notation of A.hi and
A#hi backwards, or completely wrong – A.hi is the class method, and
A#hi
is the instance method.)
Therefore, in B#hi, self.class.superclass does not refer to the
superclass
of B – rather it refers to the metaclass of the super of B. If it
pointed
to the superclass of B, then calling
self.class.superclass.hi
would print “hi”, instead of “A.hi”
This isn’t what is wanted when calling super.someMethod (that would
be like doing super.class.someMethod, which is different). I
recognize Ruby is different from other langauges, but many other
languages (even less OO capable languages such as Java and C++) have
the use of the “super.someMethod” functionality.Well… it’s probably good that Ruby isn’t a superset of those less OO
capable languages
I’m not suggesting that Ruby be a superset of those languages (and I’m
glad it isn’t) – I’m suggesting that the other languages got the
terminology right in using both the “self” and the “super” keywords in
the
same context.
But I’m getting confused by the use of an existing keyword to describe a
new concept. Also, it’s not clear what the keyword would actually
produce. You’re sending the someMethod message to it, but from what I
understand you don’t really mean it to respond to that method, but
rather to re-send the message to the current self, using the constraint
that the currently visible version of the method be skipped.
I do want the message to be responded to. Calling super.someMethod would
pass the someMethod message to the super object. The message is not
being
re-sent to any object, nor is it being routed through any object. It is
being sent directly to the super object.
“super” would either point to the superclass of self (the instance
version), or (in the case of self.class.super), would refer to the
metaclass of the superclass of self.
Perhaps Matz wants to keep the metaclass completely hidden from the
programmer (indeed, it is hinted so in Programming Ruby), and I can see
the merits in doing so. This still requires more work for the programmer
to be able to perform what was stated earlier in this thread.
Nate
On Fri, 25 Aug 2006, ts wrote:
“N” == Nathan S. [email protected] writes:
N> Therefore, in B#hi, self.class.superclass does not refer to the superclass
N> of B – rather it refers to the metaclass of the super of B. If it pointedno, not really. self.class.superclass make reference to the superclass of
B
It refers to the metaclass of the superclass of B – see Programming
Ruby
pp. 380-381.
N> to the superclass of B, then calling
N> self.class.superclass.hi
N> would print “hi”, instead of “A.hi”
no, if self.class.superclass == A then self.class.superclass.hi is the
same than A.hi, and ruby will print “A.hi”
Inside of a class instance method, self.class returns a reference to the
metaclass of the class. Calling superclass on the metaclass returns
another metaclass, and you’re right – it will print A.hi (as I said =])
Nate
“N” == Nathan S. [email protected] writes:
N> Inside of a class instance method, self.class returns a reference to
the
N> metaclass of the class. Calling superclass on the metaclass returns
N> another metaclass, and you’re right – it will print A.hi (as I said
=])
re read your example
N> class B < A
N> def hi
N> self.class.superclass.hi
N> end
N> end
moulon% cat b.rb
#!/usr/bin/ruby
class A
end
class B < A
def hi
p self.class
p class << self.class; self end
end
end
B.new.hi
moulon%
moulon% ./b.rb
B
#Class:B
moulon%
You really think that self.class, i.e. B, make reference to the
singleton
class of B ?
Guy Decoux
“N” == Nathan S. [email protected] writes:
N> metaclass != singleton class
Well, it’s well known : metaclass exist in Smalltalk, singleton class
in
ruby. Nothing new
Guy Decoux
On Fri, 25 Aug 2006, ts wrote:
“N” == Nathan S. [email protected] writes:
N> Inside of a class instance method, self.class returns a reference to the
N> metaclass of the class. Calling superclass on the metaclass returns
N> another metaclass, and you’re right – it will print A.hi (as I said =])
Guy Decoux
You really think that self.class, i.e. B, make reference to the singleton
class of B ?
Re-read what I wrote:
N> Inside of a class instance method, self.class returns a reference to
the metaclass of the class.
metaclass != singleton class
Nate
“N” == Nathan S. [email protected] writes:
N> That’s great. Thanks for the info 
I’m referring to metaclass as
stated
N> in Programming Ruby, not smalltalk.
Re read carefully “Programming Ruby”, it was written by someone which
know
ruby better than you …
Guy Decoux
On Fri, 25 Aug 2006, ts wrote:
“N” == Nathan S. [email protected] writes:
N> metaclass != singleton class
Well, it’s well known : metaclass exist in Smalltalk, singleton class in
ruby. Nothing new
That’s great. Thanks for the info I’m referring to metaclass as
stated
in Programming Ruby, not smalltalk.
Nate
On Fri, 25 Aug 2006, ts wrote:
“N” == Nathan S. [email protected] writes:
N> That’s great. Thanks for the info
N> in Programming Ruby, not smalltalk.Re read carefully “Programming Ruby”, it was written by someone which know
ruby better than you …
Rather than making rash statements such as that, it’d be nice of you to
successfully debunk my arguments. Keep trying, I have faith in you.
Nate
On Fri, 25 Aug 2006 [email protected] wrote:
class C
puts “A.hi”
end
Yes, because B.new.class.superclass is A, and A responds to “hi”. The
Therefore, in B#hi, self.class.superclass does not refer to the superclass
I think you’re adding an extra level of reference or indirection or
irb(main):005:0> Object.object_id
=> 1683084
irb(main):006:0> class << C; object_id; end
=> 1615554As you can see, the singleton class of C is not the same object as
either C or the class of C.(“Singleton class” is the most general term; the Pickaxe uses
“metaclass” to mean singleton class of a Class object. I tend to just
use “singleton”.)
I concede your point – I was using singleton as the object-specific
class, while it is the opposite of that. Thanks for the clarification.
Maybe now my arguments will make more sense!
Nate
Morton G. wrote:
A more correct conclusion would have been that Ruby’s ‘super’ should
be regarded more as a method call rather than as a pseudo-variable
(such as ‘self’). This is quite different than the ‘super’ of
Smalltalk and other object-oriented languages I have past experience
with.
Ruby follows Eiffel’s lead in this regard.
– Jim W.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs