Call functions of superclass

[Julian 'Julik' Tarkhanov]

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 )

 

[dblack]

Hi --

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

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

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

 

[dblack]

Hi --

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.

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

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

 

[Trans]

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.