Re: Non-overridable and non-redefinable methods

On 8/19/05, Eric Mahurin <[e-mail]> wrote:
> 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__ and #__send__ are already not overridable. I would suggest that
other common methods that shouldn't be overridable use the same pattern.
I think that #__class__ is a good candidate, and maybe a couple of
others that represent functionality that is rarely extended. But I think
your list of methods is far too large, and I do not believe that
non-core methods should ever be marked non-overridable. I don't care who
you are as a library writer, I may have a need or reason to override
your method.

I don't know enough about VM performance stuff, but I'm not willing to
compromise the power of Ruby for the sake of compilers. We already
have that. It's called C++.

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]