Re: Non-overridable and non-redefinable methods

On 8/20/05, Eric Mahurin <[e-mail]> wrote:

> This would be a nice feature to have and would probably be a
> better thing to use rather than "private", but I don't think it
> really helps from an optimization standpoint.  I would assume
> C#x could still be redefined at some point so you couldn't
> easily inline it.

Yes, you're right. It doesn't really address optimization.
 
> Using the same private/protected/public/localized way for
> tagging methods, here is what I'm talking about:
> 
> class C
>   def a; "a"; end
> 
>   # can't be redefined
>   freeze_method :a
> 
>   def b; "b"; end
> 
>   # can't be overriden in derived classes
>   # should also imply that you can't redefine
>   final :b
> 
> end
> 
> class C
>   # error - trying to redefine
>   def a; "redefine-a"; end
>   # error - trying to redefine
>   def b; "redefine-c"; end
>   # no problem
>   def c; "add-c"; end
> end
> 
> class D < C
>   # no problem - C#a is left in tact
>   def a; "derived-a"; end
>   # error - trying to override #b
>   def b; "derived-b"; end
> end
> 
> c = C.new
> 
> class << c
>   # no problem - C#a is left in tact
>   # we are operating on an anonymous meta class at this point
>   # c effectively has a new class - its meta class
>   def a; "meta-a"; end
>   # error - trying to override #b
>   # the meta class is a derived class of C
>   def b; "meta-b"; end
> end
> 
> 
> Having the ability to prevent methods from being redefined is
> really just a subset of what Class#freeze does.  Having the
> ability to prevent methods from being overridden is new and at
> least useful in a few methods in Object.

One could argue that no methods should be redefinable. That classes
ought to be subclassed if they are to change at all. I think there is
good support for this. Furthermore, if there is such a thing as a
proper means of class alternation it is surely AOP.

T.