Call functions of superclass

[bartb]

On Fri, 25 Aug 2006, Mauricio F. wrote:

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

[bartb]

Hi –

On Fri, 25 Aug 2006, [email protected] wrote:

you could say exactly the same thing about Class.new, Module.new, etc.

Yes, but you can’t say the same thing about #class, which is a more
level comparison with #singleton_class.

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?

Well, I was just using module_eval to match your usage; I would
normally use class_eval for a class I’m afraid I don’t see what’s
hard to explain or use about it. You’ve got a method that returns a
Class object; you send a message to that Class object. It seems like
the most natural possible kind of sequence.

block methods in ruby save time and code scanning.

You’re ascending to a kind of bird’s-eye view, though. When it comes
to any given specific method, I’d rather examine the suitability of a
block in close-up. In this particular case, I dislike the prospect of
this equivalency:

obj.class.class_eval { … } # class_eval one method away
obj.singleton_class { … } # class_eval magically available

David

[bartb]

On 23-aug-2006, at 20:01, Mauricio F. wrote:

wow, that’s way too much work (plus thread-unsafe).

def send_super(meth, *args, &b)
self.class.superclass.instance_method(meth).bind(self).call
(*args, &b)
end

Don’t know if my response went through but I wanted to say that this
rocks now I can rest and know that “I can shall the need arise”.

Doing the above for classes/modules/foos is close but not essential :-))

[bartb]

On 8/25/06, Trans [email protected] wrote:

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.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

[bartb]

[email protected] wrote:

def singleton_class
b ? sc.module_eval &b : sc

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

So what wrong with just #singleton? That would be more reasible for
things like: ‘singleton_class.module_eval’ and
‘singleton_class.class_eval’, which would instead read simply:

singleton.module_eval
singleton.class_eval

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

Yeh. I relent.

T.

[bartb]

Hi –

On Sat, 26 Aug 2006, Rick DeNatale wrote:

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

But it’s very characteristic of Ruby. There are rather few special
cases. Objects have singleton classes (most objects, anyway); classes
are objects; therefore, classes have singleton classes. It’s
interesting to me how little the language cares, so to speak, whether
we as its users decide to name the singleton classes of classes
‘metaclasses’, or the singleton methods of classes ‘class methods’.
We’re free to do that, but at the language level the model is
consistent as between classes and other objects.

(Singleton classes of classes are a bit special-cased – in the sense
that they become each other’s superclasses – but for the most part,
classes behave as “civilians” when it comes to the singleton
mechanisms.)

Now if I might dredge up some
Smalltalk terminology, I might suggest that we call:

The singleton class of an instance its ‘behavior’ and

What would you then call its behavior? (i.e., the way it behaves)
I can’t comment on the Smalltalk aspect of the terminology, but I
don’t think it’s a good fit for Ruby singleton classes. If I have an
object obj, I don’t think the phrase “obj’s behavior” conjures up its
singleton class.

The singleton class of a class its ‘metaclass.’

Classes are about representing a ‘class’ of instances: instantiating
them and providing common behavior.

That’s the thing… An object’s ‘behavior’ is not uniquely
determined by its singleton class, so I wouldn’t want to start trying
to use that word to describe the singleton class.

David