Re: Non-overridable and non-redefinable methods

--- Austin Ziegler <[e-mail]> wrote:

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

It is a warning in 1.8.2.  I think it should be an error -
along with other key methods.

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

Like I said in a previous message, I think #equal? and #nil?
shouldn't be overridable either.  The docs say that about
#equal?.

> But I think
> your list of methods is far too large,

I'm sure it is.  I just gave a complete list that you may think
about doing this for.

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

Like I said above, this mainly applies to Object and Kernel
since everything gets these methods (and thus can easily be
optimized).  It could apply to other classes but you may not
find as much advantage.

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

I think very selective restrictions is quite fine if it has a
good payoff.

In summary, I'm talking a) the ability to disallow redefining
selective methods (not just overriding in a derived class):

Fixnum#<most methods>
String#<most methods>
Object#<most methods>
...

and b) disallowing certain methods to overridden in derived
classes (or even the ability to do so on arbitrary methods):

Object#__send__
Object#__id__
Object#equal?
Object#nil?
... possibly applied to some of the core classes too




		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs