From: Eric Hodel Date: 2005-08-20T04:03:31+09:00 Subject: 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 - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04