From: Eric Mahurin <eric_mahurin@...>
Date: 2005-08-20T02:03:37+09:00
Subject: Non-overridable and non-redefinable methods

Lately, I've been thinking about the future of ruby
performance, ruby compilers, optimizations that a ruby compiler
or VM could make, etc.  I've come to the conclusion that one
big problem in ruby is that you can redefine (or remove) a
method (of an object or an instance method of a class) at any
point while running.  Here are the problem I see with being
able to do this:

- if the compiler/VM is somehow able to recognize that a
certain variable (possibly temporary) is always a certain
class, it still can't do any optimizations for the method calls
to that object - bypassing method lookup, inlining the method,
etc.
- when writing C code for a method, many (most?) times you may
bypass calling a method of an object (inlining the code
instead) if you determine the exact class of an object.  For
example when you determine that an object is a Fixnum, you are
likely going to do a "+" directly in C rather than calling the
"+" method of Fixnum.  If somebody goes and redefines Fixnum#+,
you now have an inconsistency - C code that inlined the + will
do something different compared the ruby code that didn't.
- a similar issue can occur in ruby code where you may want to
special case a certain class for performance reasons.  Instead
of taking the normal duck-typed route, you may want to use a
different set of methods or algorithm (maybe similar to
inlining you would do in C).  If somebody redefined any of the
methods you used, it may give you a functional difference for
your special case class when you intended the functionality to
be identical (you had that special case only for performance
reasons).
- in general, it seems like not really knowing what a given
class does is a bad thing.


To solve these problems and preserve existing functionality,
I'd propose that there be a way to tag a method to not be
redefinable or removable.  Maybe similar to the way
private/protected methods are done.  I guess you could consider
class instance methods and object methods (from the metaclass)
separately.  I think the problems above mainly deal with simple
class instance methods.



Another thing that hinders performance optimizations is the
lack of the ability to say that a method is not overridable in
any derived classes.  This mostly applies to many methods in
Object and Kernel (because everything gets those methods), but
could apply elswhere if the VM/compiler couldn't determine the
exact class but possibly the kind_of.  Here are methods in
Object that would be advantageous to inline (and not allow to
be overridden) for performance:

__id__   __send__   class   equal?   extend   freeze   frozen? 
 id   instance_eval   instance_of?   instance_variable_get  
instance_variable_set   instance_variables   is_a?   kind_of?  
method   methods   nil?   object_id   private_methods  
protected_methods   public_methods   remove_instance_variable  
respond_to?   send   singleton_method_added  
singleton_method_removed   singleton_method_undefined  
singleton_methods   taint   tainted?   untaint


I'd propose something like private/protected to say these are
not overridable.

Or am I off base?  Is there another way to get this kind of
in-line performance without adding these
non-overridable/non-redefinable capabilities.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com