Re: Non-overridable and non-redefinable methods

On 19 Aug 2005, at 10:03, Eric Mahurin wrote:

> 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 either never call these methods, or would use them for making proxy  
objects.

send can be quite useful to override, and respond_to? pairs with  
method_missing, so it can't be in the list.  id is used extensively  
by Rails, and is deprecated anyhow.

I don't see why remove_instance_variable is on the list.  I may *not*  
want to remove certain instance variables.

Also, we couldn't make dead-simple proxies like this:

class BlankSlate
   instance_methods.each { |m| undef_method m unless m =~ /^__/ }
end

class Proxy < BlankSlate

   def initialize(obj)
     @obj = obj
   end

   def method_missing(sym, *args, &block)
     @obj.__send__(sym, *args, &block)
   end

end

class Foo
   def x; y; end
   protected
   def y; @y = :stuff; end
end

foo = Foo.new
dfoo = Proxy.new foo

p foo.protected_methods
p dfoo.protected_methods

p dfoo.send :x
p dfoo.instance_variables


-- 
Eric Hodel - [e-mail] - http://segment7.net
FEC2 57F1 D465 EB15 5D6E  7C11 332A 551C 796C 9F04