Call functions of superclass

[Jim Weirich]

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 Weirich

 

[Nathan Smith]

On Fri, 25 Aug 2006 (e-mail address removed) wrote:

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!

In any case, my original "want" stands, in that super be treated as an
object, and not just a keyword which facilitates a certain type of method
calling.

Nate

 

[dblack]

Hi --

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!

It doesn't sound like I clarified it.... The singleton class *is*
the object-specific class. Here's a common idiom that illustrates it:

class Object
def singleton_class
class << self
self
end
end
end

It sounds like this came out backwards -- ?


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

 

[Nathan Smith]

Hi --



It doesn't sound like I clarified it.... The singleton class *is*
the object-specific class. Here's a common idiom that illustrates it:

class Object
def singleton_class
class << self
self
end
end
end

It sounds like this came out backwards -- ?

Der. OK, I take back my concedation. Let's drop this thing. Requiring way
too much effort to get nowhere.

Nate

 

[Hal Fulton]

That's great. Thanks for the info ;-) I'm referring to metaclass as stated
in Programming Ruby, not smalltalk.

Does the 2nd edition say that??


Hal

 

[Hal Fulton]

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.

Be careful... Guy is one of the very smartest people
in this newsgroup. Probably in the top three. And no, I
don't place myself near the top.

But his English is his weak spot. It's pretty good, but
he is much more fluent in Ruby.

So, much of his conciseness is just hesitancy with English
I think.


Hal

 

[Rick DeNatale]

N> metaclass != singleton class

Well, it's well known : metaclass exist in Smalltalk, singleton class in
ruby. Nothing new

The difference's between Ruby and Smalltalk here are subtle, and
somewhat just terminology.

In both Smalltalk and Ruby, classes hold the methods of their
instances, and classes themselves must have a 'class' to hold any
class methods, which are really instance methods of the object which
represents the class.

The difference is that Ruby and Smalltalk factor things a little differently.

In Smalltalk all classes are ultimately subclasses of Class. If I
recall correctly the class Class provides the base methods for making
subclasses, since in Smalltak subclasses are created by sending a
message to the superclass. In Ruby subclass definition is done
syntactically as part of eval. In Smalltalk there is a class called
Metaclass, from which all of the classes of classes descend. The
common superclass of both Class and Metaclass is Behavior which
provides the methods involved with holding methods. To some extent
the Module class in Ruby serves some of the purposes of Behavior in
Smalltalk, although Smalltalk doesn't have the concepts of name
scoping and implementation mixing which the Ruby Module provides.

And touching on the theme of this particular thread, there's been some
confusion about just what super means. It's not really a 'reference'
to the superclass of self in a method, it's a 'reference' to the
superclass of the class which contains the method, which may well be a
superclass of the class of self. In both Smalltalk and Ruby, the
objects which contain methods i.e descendants of Behavior in
Smalltalk, or Module in Ruby, act as nodes in a tree which is searched
for methods when they are invoked. Normally when a message is sent to
an object, the search starts in that object's class, and goes up the
superclass chain until it is found, or if the chain runs out, the
bailout method is called instead, method_missing in Ruby, or
doesNotUnderstand: in Smalltalk. In both Ruby and Smalltalk, super is
a syntactic construct which causes the search to start just above the
point where the current method was found.

One aspect of Smalltalk which I miss in Ruby is that it provided
deeper reflection, not just at the class level, but also at the method
level. Smalltalk method objects can do things like enumerate the
messages they send, which is very useful in developing an IDE.

Matz is reluctant to call the class of a Ruby class a metaclass,
although it serves much of the same purpose in Ruby as a Smalltalk
Metaclass. Since Ruby already has singleton classes to provide
instance-specific behavior, another way of thinking about classes of
classes in Ruby is as singleton classes of classes, which seems to be
Matz's preferred way of viewing them. One difference is that instance
singletons aren't created until they are needed, while the class of a
class is created along with the class.

I'm pretty sure that the delay in creating a 'class' for instance
behavior is why they are called singleton classes, in effect a
singleton pattern is used to ensure that a given instance has at most
one class to hold it's instance specific behavior.

I had been thinking that the class of a class in Ruby could also be
lazily constructed, but in typing this note, I realized that they need
to be instantiated along with a new class because there needs to be a
place to start looking for methods when a message is sent to a class.
I guess an alternate implementation in Ruby might have been to make
the intial class of a new class, the class of it's first superclass
which had one, and then change that when class methods were added, but
I suspect that such an implementation would be messier than the simple
expedient of just creating an empty meta/singleton class.

Sorry for the long post. I've been working on something for my blog
on this very topic for about two weeks, and this chain of
consciousness just started pouring out.. I guess I'll store it away as
fodder for that article.

 

[ts]

R> The difference's between Ruby and Smalltalk here are subtle, and
R> somewhat just terminology.

It depend how you see it. A class is an instance of the Metaclass
(i.e. the class of the class is a metaclass), you can't say the same for a
singleton class.

Any object can have a singleton class.

To explain the parallel hierachy between the classes and the metaclasses,
you must speak about the compatibility problem.

In ruby you just need to say that a class is an object.


Guy Decoux

 

[ts]

H> Does the 2nd edition say that??

Well the 2nd edition speak about the metaclass and there is a paragraph in
page 382 to explain the use of the term metaclass in the book.

 

[dblack]

Hi --

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 }

I'd rather not see module_eval wrapped/hidden in singleton_class. I
see singleton_class as a kind of twin method with class. In part I'm
hoping for this because I think it will make it vastly easier for
people to understand the basic premise that an object has a [birth]
class and a singleton class, from both of which it draws its
behaviors. I don't see an advantage to adding a special twist to
singleton_class. If it gives you a class object, you can always call
module_eval on that, as with any class object.


David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black => book, Ruby for Rails
http://www.rubycentral.org => Ruby Central, Inc.

 

[Austin Ziegler]

While we are at adding methods, who else would like ot have a method
that returns the current block, so you can access it without needing
to declare it in the arguments list? (And likewise for lambda{}, even
if 1.9 fixes that.)

Um. Me. That would totally rock.

def foo
blah
blah
my_block = current_block if block_given?
end

That would mean that I wouldn't need block boxing unless that path was
taken in code.

-austin

 

[ts]

A> def foo
A> blah
A> blah
A> my_block = current_block if block_given?

moulon% cat b.rb
#!/usr/bin/ruby
def blah
end

def foo
blah
blah
my_block = Proc.new if block_given?
p my_block
end

foo
foo {}
moulon%

moulon% ./b.rb
nil
#<Proc:0x00000000@./b.rb:13>
moulon%


Guy Decoux

 

[Austin Ziegler]

moulon% cat b.rb
#!/usr/bin/ruby
def blah
end

def foo
blah
blah
my_block = Proc.new if block_given?
p my_block
end

foo
foo {}
moulon%

moulon% ./b.rb
nil
#<Proc:0x00000000@./b.rb:13>
moulon%

Cool. I didn't know that.

-austin

 

[Mauricio Fernandez]

While we are at adding methods, who else would like ot have a method
that returns the current block, so you can access it without needing
to declare it in the arguments list? (And likewise for lambda{}, even
if 1.9 fixes that.)

Like Proc.new ?
IIRC there were plans to deprecate it in 1.9, so that request seems to go
against the tide of change (but it still seems to work, though):

RUBY_VERSION # => "1.8.5"
RUBY_RELEASE_DATE # => "2006-08-25"
def a; Proc.new.call end
a {1+1} # => 2

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
def a; Proc.new.call end
a{1+1} # => 2

 

[Trans]

+100 - please give us singleton_class!


+1 to this implementation.

At the very least, 'singleton_class' is too long. Just 'singleton'
would suffice.

Alas, I wish we could just go back to 'metaclass'.

T.

 

[ara.t.howard]

I'd rather not see module_eval wrapped/hidden in singleton_class. I
see singleton_class as a kind of twin method with class. In part I'm
hoping for this because I think it will make it vastly easier for
people to understand the basic premise that an object has a [birth]
class and a singleton class, from both of which it draws its
behaviors. I don't see an advantage to adding a special twist to
singleton_class. If it gives you a class object, you can always call
module_eval on that, as with any class object.

you could say exactly the same thing about Class.new, Module.new, etc. i
think the advatage is that

obj = Object.new

obj.singleton_class.module_eval{ def foo() 42 end }
^^^^^^^^^^^^^^^ ^^^^^^^^^^^
^^^^^^^^^^^^^^^ ^^^^^^^^^^^
hard to explain. harder. where's the module?


block methods in ruby save time and code scanning.

2 cts.

-a

 

[ara.t.howard]

Like Proc.new ?
IIRC there were plans to deprecate it in 1.9, so that request seems to go
against the tide of change (but it still seems to work, though):

RUBY_VERSION # => "1.8.5"
RUBY_RELEASE_DATE # => "2006-08-25"
def a; Proc.new.call end
a {1+1} # => 2

RUBY_VERSION # => "1.9.0"
RUBY_RELEASE_DATE # => "2006-08-13"
def a; Proc.new.call end
a{1+1} # => 2

i use

harp:~ > cat a.rb
def foo()
b = lambda{|*a| yield *a} if block_given?
b[42] if b
end

foo
foo{|n| p n}

harp:~ > ruby a.rb
42


-a

 

[ara.t.howard]

At the very least, 'singleton_class' is too long. Just 'singleton'
would suffice.

Alas, I wish we could just go back to 'metaclass'.

i too would like a shorter namer, but singleton_class is in the source and has
been for years. momentum! ;-)

seriously though - the name comes up in google - and we all know how important
that it for newbies!

-a

 

[Nate Smith]

Does the 2nd edition say that??

Yes AFAIK I was referring to the 2nd edition (don't have the book in
front of me now.)

Nate

 

[Rick DeNatale]

At the very least, 'singleton_class' is too long. Just 'singleton'
would suffice.

Alas, I wish we could just go back to 'metaclass'.

It's probably my Smalltalk background, but metaclass bothers me as a
name for a singleton class which holds INSTANCE specific methods for a
non-class.

On the other hand, metaclass fits perfectly in my mind for naming a
singleton class of a CLASS which holds the class methods for that
class.

The fact that in the ruby implementation, both of these are singleton
classes is an accident of implementation (in the sense of accidental
being the antonym of essential). Now if I might dredge up some
Smalltalk terminology, I might suggest that we call:

The singleton class of an instance its 'behavior' and
The singleton class of a class its 'metaclass.'

Classes are about representing a 'class' of instances: instantiating
them and providing common behavior. Despite what folks like why have
written, metaclasses really should be considered something which is a
feature of classes and not any arbitrary object. That's why the word
is metaCLASS.

The term 'behavior' here, as is about simply having behavior (i.e. a
set of methods).

Of course all three of these things (behavior, class, and metaclass)
are also just links on the chain of objects which define all the
methods inherited by an object, or a class.

The more I think about this the more I like the terminology,

But that's just what I think.