# Adding a dynamic method handler? (long post) **URL:** \ **Category:** ruby-talk\ **Created:** [16 February 2005 07:04 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515 "2005-02-16T07:04:10Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Mark\_Hubbart1](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Mark\_Hubbart1](https://rubytalk.org/u/Mark_Hubbart1)\ **Post date:** [16 February 2005 07:04 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/1 "2005-02-16T07:04:10Z")
Hi, I've been using method\_missing overly much in my code lately, and it's prompted me to think a lot about it's limitations. I've been wishing for a version of method\_missing that allows the dynamic methods to act more like they are real methods on the object. I think this could be done by implementing a new method hook especially for dynamic methods: dynamic\_method. dynamic\_method would be called before method\_missing if a method lookup fails. If dynamic\_method fails to handle the message, method\_missing will recieve the message for handling. A couple of the immediate benefits afforded by a good implementation of a dynamic method handler: - the object will respond\_to? the method - you can call method(:foo) to get a copy of the dynamic method. dynamic\_method would be used something like this:   class Foo     def dynamic\_method(name)       if name.to\_s =~ /^foo/         # create the method (as a proc)         return lambda do |\*args|           args.map{|arg| name.to\_s.sub(/^foo/, arg.to\_s) }         end       end     end   end   f = Foo.new     ==\>#\   f.respond\_to? :foobar     ==\>true   f.respond\_to? :barfoo     ==\>false   f.foobar(\*%w[one two three])     ==\>["onebar", "twobar", "threebar"]   f.barfoo(\*%w[one two three])   NoMethodError: undefined method `barfoo' for #\      f.method(:foobaz).call(\*%w[one two three])     ==\>["onebaz", "twobaz", "threebaz"] As you can see, a user-defined dynamic\_method returns either a callable object (Proc, Method, etc) or nil. If dynamic\_method(message) returns nil, it is assumed that the object does not respond\_to?(message), and method(message) should raise a NoMethodError. And here's a lightweight example implementation:   module Kernel     alias\_method :old\_method\_missing, :method\_missing     def method\_missing(name, \*args, &block)       m = dynamic\_method(name)       if m         m.call(\*args, &block)       else         m = Kernel.instance\_method(:old\_method\_missing)         m.bind(self).call(name, \*args, &block)       end     end          alias\_method :old\_respond\_to?, :respond\_to?     def respond\_to?(msg)       (old\_respond\_to?(msg) || dynamic\_method(msg)) ? true : false     end          alias\_method :old\_method, :method     def method(name)       old\_method(name)     rescue NameError =\> e       m = dynamic\_method(name)       raise e unless m       m     end          def dynamic\_method(name)       nil     end   end Here's a lightweight version of OpenStruct written using dynamic\_method:   class OpenStruct     def initialize(hash = {})       @table = {}       hash.each do |key, value|         @table[key.to\_sym] = value       end     end          def dynamic\_method(name)       if name.to\_s =~ /\=\z/         lambda{|val| @table[name.to\_s.chop.intern] = val }       elsif @table.keys.include?(name)         lambda{ @table[name] }       end     end   end    And using it:   os = OpenStruct.new     ==\>#\   os.red = 23     ==\>23   os.blue = 42     ==\>42   os.green = 56     ==\>56   os.respond\_to? :blue     ==\>true   os.respond\_to? :periwinkle     ==\>false   os\_blue = os.method(:blue)     ==\>#\   os.blue = 1024     ==\>1024   os\_blue.call     ==\>1024 This is not a complete idea (let alone implementation) at this time... I just wanted to see if anyone had an opinion on whether the idea was worth anything, or could make suggestions to improve the interface. Now here's me second-guessing myself: The implementation is pretty complicated; adding another dynamic message handler may not be worth the confusion. It would be one more thing to explain to people, and while method\_missing is an elegant addition to a language, I'm not sure this would be. Especially considering the need to add more complexity to method lookups. Still, I think that even if this idea here isn't worthy, putting it out there might help someone else come up with a more elegant solution. So, any thoughts? cheers, Mark ---
**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\ **Post date:** [16 February 2005 09:19 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/2 "2005-02-16T09:19:50Z")
"Mark Hubbart" \ schrieb im Newsbeitrag news:de63abca0502152303763354f7@mail.gmail.com... > Hi, > > I've been using method\_missing overly much in my code lately, and it's > prompted me to think a lot about it's limitations. \ > So, any thoughts? I'm wondering in which situation you need this. Although I understand the benefits of your approach I don't see the use case for this. Kind regards     robert ---
**Author:** ![benny1](https://avatars.discourse-cdn.com/v4/letter/b/ecc23a/32.png) [@benny1](https://rubytalk.org/u/benny1)\ **Post date:** [18 February 2005 16:29 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/3 "2005-02-18T16:29:46Z")
Mark Hubbart wrote: > I've been wishing > for a version of method\_missing that allows the dynamic methods to act > more like they are real methods on the object. I am not sure what you mean by dynamic methods. But in case only Structs are concerned wouldn't it make more sence to redefine method\_missing for \*Structs(Open-Super, ...).? benny ---
**Author:** ![Mark\_Hubbart1](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Mark\_Hubbart1](https://rubytalk.org/u/Mark_Hubbart1)\ **Post date:** [16 February 2005 20:53 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/4 "2005-02-16T20:53:05Z")
Basically this is for any time that you want the code re-use and ease of implementation afforded by method\_missing, but the benefits of still having the methods behave mostly as if they were actually defined, rather than handled dynamically. This is useful for quickly defining wrapper objects, or objects that delegate to multiple other objects. The idea is that this would be a way of dynamically creating methods for an object, without resorting to relatively permanent methods like "class \<\< self; define\_method(:foo){...}; end". cheers, Mark > **···** > > On Wed, 16 Feb 2005 18:19:50 +0900, Robert Klemme \ wrote: > > > "Mark Hubbart" \ schrieb im Newsbeitrag > > news:de63abca0502152303763354f7@mail.gmail.com... > > \> Hi, > > \> > > \> I've been using method\_missing overly much in my code lately, and it's > > \> prompted me to think a lot about it's limitations. > > > > \ > > > > \> So, any thoughts? > > > > I'm wondering in which situation you need this. Although I understand the > > benefits of your approach I don't see the use case for this. ---
**Author:** ![Sam\_Roberts](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sam\_Roberts](https://rubytalk.org/u/Sam_Roberts)\ **Post date:** [16 February 2005 23:56 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/5 "2005-02-16T23:56:34Z")
Wrote Robert Klemme \, on Wed, Feb 16, 2005 at 06:19:50PM +0900: > "Mark Hubbart" \ schrieb im Newsbeitrag > news:de63abca0502152303763354f7@mail.gmail.com... > \> Hi, > \> > \> I've been using method\_missing overly much in my code lately, and it's > \> prompted me to think a lot about it's limitations. > > \ > > \> So, any thoughts? > > I'm wondering in which situation you need this. Although I understand the > benefits of your approach I don't see the use case for this. I think I see what Mark was getting at. As I understand it, if I defined a proxy object that used method\_missing to forward all method calls to an underlying object, I could call   proxy.to\_ary and if the underlying object was an Array, this would work. However, if I passed that into a library that was using duck-typing, and that lib did   proxy.responds\_to? :to\_ary the answer would be false. So, my Array proxy doesn't look as much like an Array as it needs to. Do I understand correctly? Cheers, Sam > **···** > > -- > Sam Roberts \ ---
**Author:** ![benny1](https://avatars.discourse-cdn.com/v4/letter/b/ecc23a/32.png) [@benny1](https://rubytalk.org/u/benny1)\ **Post date:** [18 February 2005 16:29 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/6 "2005-02-18T16:29:47Z")
benny wrote: > Mark Hubbart wrote: > > > I've been wishing > > for a version of method\_missing that allows the dynamic methods to act > > more like they are real methods on the object. > > I am not sure what you mean by dynamic methods. But in case only Structs > are concerned wouldn't it make more sence to redefine method\_missing for > \*Structs(Open-Super, ...).? > > benny Oh, I am sorry: this was kind of stupid, since method\_missing belongs to Kernel ☹ benny ---
**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\ **Post date:** [17 February 2005 08:19 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/7 "2005-02-17T08:19:54Z")
"Mark Hubbart" \ schrieb im Newsbeitrag news:de63abca050216125273686a45@mail.gmail.com... > \> > \> "Mark Hubbart" \ schrieb im Newsbeitrag > \> news:de63abca0502152303763354f7@mail.gmail.com... > \> \> Hi, > \> \> > \> \> I've been using method\_missing overly much in my code lately, and it's > \> \> prompted me to think a lot about it's limitations. > \> > \> \ > \> > \> \> So, any thoughts? > \> > \> I'm wondering in which situation you need this. Although I understand the > \> benefits of your approach I don't see the use case for this. > > Basically this is for any time that you want the code re-use and ease > of implementation afforded by method\_missing, but the benefits of > still having the methods behave mostly as if they were actually > defined, rather than handled dynamically. This is useful for quickly > defining wrapper objects, or objects that delegate to multiple other > objects. > > The idea is that this would be a way of dynamically creating methods > for an object, without resorting to relatively permanent methods like > "class \<\< self; define\_method(:foo){...}; end". I'm sorry if I am being stubborn (or dump), but this is still pretty much abstract. I'd like to know which concrete use case made this behavior necessary. Kind regards     robert > **···** > > > On Wed, 16 Feb 2005 18:19:50 +0900, Robert Klemme \ wrote: ---
**Author:** ![Mark\_Hubbart1](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Mark\_Hubbart1](https://rubytalk.org/u/Mark_Hubbart1)\ **Post date:** [17 February 2005 17:55 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/8 "2005-02-17T17:55:53Z")
Yes, that's the general rationale I had for this. Getting more of the reflection methods to work for dynamically defined methods. cheers, Mark > **···** > > On Thu, 17 Feb 2005 08:56:34 +0900, Sam Roberts \ wrote: > > > Wrote Robert Klemme \, on Wed, Feb 16, 2005 at 06:19:50PM +0900: > > \> > > \> "Mark Hubbart" \ schrieb im Newsbeitrag > > \> news:de63abca0502152303763354f7@mail.gmail.com... > > \> \> Hi, > > \> \> > > \> \> I've been using method\_missing overly much in my code lately, and it's > > \> \> prompted me to think a lot about it's limitations. > > \> > > \> \ > > \> > > \> \> So, any thoughts? > > \> > > \> I'm wondering in which situation you need this. Although I understand the > > \> benefits of your approach I don't see the use case for this. > > > > I think I see what Mark was getting at. As I understand it, if I defined > > a proxy object that used method\_missing to forward all method calls to > > an underlying object, I could call > > > >   proxy.to\_ary > > > > and if the underlying object was an Array, this would work. > > > > However, if I passed that into a library that was using duck-typing, and > > that lib did > > > >   proxy.responds\_to? :to\_ary > > > > the answer would be false. So, my Array proxy doesn't look as much like > > an Array as it needs to. > > > > Do I understand correctly? ---
**Author:** ![benny1](https://avatars.discourse-cdn.com/v4/letter/b/ecc23a/32.png) [@benny1](https://rubytalk.org/u/benny1)\ **Post date:** [18 February 2005 16:29 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/9 "2005-02-18T16:29:55Z")
benny wrote: > benny wrote: > > > Mark Hubbart wrote: > > > > > I've been wishing > > > for a version of method\_missing that allows the dynamic methods to act > > > more like they are real methods on the object. > > > > I am not sure what you mean by dynamic methods. But in case only Structs > > are concerned wouldn't it make more sence to redefine method\_missing for > > \*Structs(Open-Super, ...).? > > > > benny > > Oh, I am sorry: this was kind of stupid, since method\_missing belongs to > Kernel ☹ > > benny I had expected it to be part of Object (would be way more flexible IMHO) benny ---
**Author:** ![Mark\_Hubbart1](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Mark\_Hubbart1](https://rubytalk.org/u/Mark_Hubbart1)\ **Post date:** [17 February 2005 17:53 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/10 "2005-02-17T17:53:10Z")
Maybe stubborn, but that's not always a bad thing. There are many things I'm very glad Matz is stubborn about 🙂 I don't think I ever implied that this behavior was \*necessary\*. You can implement similar functionality with what is currently available. It's just a pain in the neck to do it; You either have to break down and def a bunch of methods, or override respond\_to? and method in your class. And sometimes neither of those is the \*best\* solution. I did give a specific use case where it would be very useful, though. When wrapping a class, or doing runtime refactoring (like what pathname does, which is, for the most part, a refactored wrapper for File and Dir), this could be very handy. Like method\_missing, it would allow you to handle large amounts of similar methods at once, letting you condense code; while still getting almost all the benefits of actually defining each individual method.   class DirectoryItem     def initialize(path)       @path = path     end     [...]     def dynamic\_method(name)       @@file\_methods = (File.methods - Object.methods).map{|s|s.to\_sym}       @@dir\_methods = (Dir.methods - Object.methods).map{|s|s.to\_sym}       if @@file\_methods.include? name         if File.method(name).arity == 1           lambda{ File.send(name, @path) }         elsif name == :truncate           lambda{|len| File.send(name, @path, len) }         elsif File.method(name).arity == 2           lambda{|path| File.send(name, @path, path) }         end       elsif @@dir\_methods.include? name         # handle Dir methods here       end     end   end The equivalent portion of code using 'def' would be much, much longer, and very repetitive. The equivalent code using method\_missing would be about the same length, but if anyone tried to check it's capabilities, it would seem to almost be an empty object. cheers, Mark > **···** > > On Thu, 17 Feb 2005 17:19:54 +0900, Robert Klemme \ wrote: > > > "Mark Hubbart" \ schrieb im Newsbeitrag > > news:de63abca050216125273686a45@mail.gmail.com... > > \> On Wed, 16 Feb 2005 18:19:50 +0900, Robert Klemme \ \> wrote: > > \> \> > > \> \> "Mark Hubbart" \ schrieb im Newsbeitrag > > \> \> news:de63abca0502152303763354f7@mail.gmail.com... > > \> \> \> Hi, > > \> \> \> > > \> \> \> I've been using method\_missing overly much in my code lately, and > > it's > > \> \> \> prompted me to think a lot about it's limitations. > > \> \> > > \> \> \ > > \> \> > > \> \> \> So, any thoughts? > > \> \> > > \> \> I'm wondering in which situation you need this. Although I understand > > the > > \> \> benefits of your approach I don't see the use case for this. > > \> > > \> Basically this is for any time that you want the code re-use and ease > > \> of implementation afforded by method\_missing, but the benefits of > > \> still having the methods behave mostly as if they were actually > > \> defined, rather than handled dynamically. This is useful for quickly > > \> defining wrapper objects, or objects that delegate to multiple other > > \> objects. > > \> > > \> The idea is that this would be a way of dynamically creating methods > > \> for an object, without resorting to relatively permanent methods like > > \> "class \<\< self; define\_method(:foo){...}; end". > > > > I'm sorry if I am being stubborn (or dump), but this is still pretty much > > abstract. I'd like to know which concrete use case made this behavior > > necessary. ---
**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://rubytalk.org/u/Robert)\ **Post date:** [18 February 2005 08:39 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/11 "2005-02-18T08:39:47Z")
"Mark Hubbart" \ schrieb im Newsbeitrag news:de63abca050217095240cde47c@mail.gmail.com... > \> > \> "Mark Hubbart" \ schrieb im Newsbeitrag > \> news:de63abca050216125273686a45@mail.gmail.com... > \> \> \> > \> \> \> "Mark Hubbart" \ schrieb im Newsbeitrag > \> \> \> news:de63abca0502152303763354f7@mail.gmail.com... > \> \> \> \> Hi, > \> \> \> \> > \> \> \> \> I've been using method\_missing overly much in my code lately, and > \> it's > \> \> \> \> prompted me to think a lot about it's limitations. > \> \> \> > \> \> \> \ > \> \> \> > \> \> \> \> So, any thoughts? > \> \> \> > \> \> \> I'm wondering in which situation you need this. Although I understand > \> the > \> \> \> benefits of your approach I don't see the use case for this. > \> \> > \> \> Basically this is for any time that you want the code re-use and ease > \> \> of implementation afforded by method\_missing, but the benefits of > \> \> still having the methods behave mostly as if they were actually > \> \> defined, rather than handled dynamically. This is useful for quickly > \> \> defining wrapper objects, or objects that delegate to multiple other > \> \> objects. > \> \> > \> \> The idea is that this would be a way of dynamically creating methods > \> \> for an object, without resorting to relatively permanent methods like > \> \> "class \<\< self; define\_method(:foo){...}; end". > \> > \> I'm sorry if I am being stubborn (or dump), but this is still pretty much > \> abstract. I'd like to know which concrete use case made this behavior > \> necessary. > > Maybe stubborn, but that's not always a bad thing. There are many > things I'm very glad Matz is stubborn about 🙂 > > I don't think I ever implied that this behavior was \*necessary\*. You > can implement similar functionality with what is currently available. > It's just a pain in the neck to do it; You either have to break down > and def a bunch of methods, or override respond\_to? and method in your > class. And sometimes neither of those is the \*best\* solution. > > I did give a specific use case where it would be very useful, though. > When wrapping a class, or doing runtime refactoring (like what > pathname does, which is, for the most part, a refactored wrapper for > File and Dir), this could be very handy. Like method\_missing, it would > allow you to handle large amounts of similar methods at once, letting > you condense code; while still getting almost all the benefits of > actually defining each individual method. > >   class DirectoryItem >     def initialize(path) >       @path = path >     end >     [...] >     def dynamic\_method(name) >       @@file\_methods = (File.methods - Object.methods).map{|s|s.to\_sym} >       @@dir\_methods = (Dir.methods - Object.methods).map{|s|s.to\_sym} >       if @@file\_methods.include? name >         if File.method(name).arity == 1 >           lambda{ File.send(name, @path) } >         elsif name == :truncate >           lambda{|len| File.send(name, @path, len) } >         elsif File.method(name).arity == 2 >           lambda{|path| File.send(name, @path, path) } >         end >       elsif @@dir\_methods.include? name >         # handle Dir methods here >       end >     end >   end > > The equivalent portion of code using 'def' would be much, much longer, > and very repetitive. The equivalent code using method\_missing would be > about the same length, but if anyone tried to check it's capabilities, > it would seem to almost be an empty object. Although I agree to that - wouldn't it be more efficient to define all forwarding methods in DirectoryItem class once and for all? That way you get these benefits: - faster as methods can be invoked directly and no lambdas have to be created - reduced mem usage as not every instance has its own copy of the lambdas Drawback is of course that methods added to File and Dir later don't get invoked - but it's unlikely in this case I'd say. Also, a suggestion for improvement: wrap dynamic\_method with a method similar to this, which will reduce the number of created lambdas: # untested def dyn\_create(name)   m = dynamic\_method(name)   class\<\ **···** > > > On Thu, 17 Feb 2005 17:19:54 +0900, Robert Klemme \ wrote: > > \> \> On Wed, 16 Feb 2005 18:19:50 +0900, Robert Klemme \ \> \> wrote: ---
**Author:** ![Mark\_Hubbart1](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@Mark\_Hubbart1](https://rubytalk.org/u/Mark_Hubbart1)\ **Post date:** [19 February 2005 01:04 UTC](https://rubytalk.org/t/adding-a-dynamic-method-handler-long-post/16515/12 "2005-02-19T01:04:37Z")
That's an interesting way of doing it. I suppose if at a later time the method needs to be modified, you could always undef it and let the dyn\_create method catch it the next time through. On the other hand, the more I think about this, the more complicated it seems to get. I'm not really as gung ho on the idea as when I first thought of it. Maybe if it was worked into the syntax somehow, it would be worthwhile; but I wouldn't know where to start. Perhaps a better way to go would be to make it easier to wrap respond\_to?() and methods(). Which is coming in 2.0 anyway 🙂 cheers, Mark > **···** > > On Fri, 18 Feb 2005 17:39:47 +0900, Robert Klemme \ wrote: > > > "Mark Hubbart" \ schrieb im Newsbeitrag > > news:de63abca050217095240cde47c@mail.gmail.com... > > \> On Thu, 17 Feb 2005 17:19:54 +0900, Robert Klemme \ \> wrote: > > \> \> > > \> \> "Mark Hubbart" \ schrieb im Newsbeitrag > > \> \> news:de63abca050216125273686a45@mail.gmail.com... > > \> \> \> On Wed, 16 Feb 2005 18:19:50 +0900, Robert Klemme \ \> \> \> wrote: > > \> \> \> \> > > \> \> \> \> "Mark Hubbart" \ schrieb im Newsbeitrag > > \> \> \> \> news:de63abca0502152303763354f7@mail.gmail.com... > > \> \> \> \> \> Hi, > > \> \> \> \> \> > > \> \> \> \> \> I've been using method\_missing overly much in my code lately, > > and > > \> \> it's > > \> \> \> \> \> prompted me to think a lot about it's limitations. > > \> \> \> \> > > \> \> \> \> \ > > \> \> \> \> > > \> \> \> \> \> So, any thoughts? > > \> \> \> \> > > \> \> \> \> I'm wondering in which situation you need this. Although I > > understand > > \> \> the > > \> \> \> \> benefits of your approach I don't see the use case for this. > > \> \> \> > > \> \> \> Basically this is for any time that you want the code re-use and > > ease > > \> \> \> of implementation afforded by method\_missing, but the benefits of > > \> \> \> still having the methods behave mostly as if they were actually > > \> \> \> defined, rather than handled dynamically. This is useful for quickly > > \> \> \> defining wrapper objects, or objects that delegate to multiple other > > \> \> \> objects. > > \> \> \> > > \> \> \> The idea is that this would be a way of dynamically creating methods > > \> \> \> for an object, without resorting to relatively permanent methods > > like > > \> \> \> "class \<\< self; define\_method(:foo){...}; end". > > \> \> > > \> \> I'm sorry if I am being stubborn (or dump), but this is still pretty > > much > > \> \> abstract. I'd like to know which concrete use case made this behavior > > \> \> necessary. > > \> > > \> Maybe stubborn, but that's not always a bad thing. There are many > > \> things I'm very glad Matz is stubborn about 🙂 > > \> > > \> I don't think I ever implied that this behavior was \*necessary\*. You > > \> can implement similar functionality with what is currently available. > > \> It's just a pain in the neck to do it; You either have to break down > > \> and def a bunch of methods, or override respond\_to? and method in your > > \> class. And sometimes neither of those is the \*best\* solution. > > \> > > \> I did give a specific use case where it would be very useful, though. > > \> When wrapping a class, or doing runtime refactoring (like what > > \> pathname does, which is, for the most part, a refactored wrapper for > > \> File and Dir), this could be very handy. Like method\_missing, it would > > \> allow you to handle large amounts of similar methods at once, letting > > \> you condense code; while still getting almost all the benefits of > > \> actually defining each individual method. > > \> > > \> class DirectoryItem > > \> def initialize(path) > > \> @path = path > > \> end > > \> [...] > > \> def dynamic\_method(name) > > \> @@file\_methods = (File.methods - Object.methods).map{|s|s.to\_sym} > > \> @@dir\_methods = (Dir.methods - Object.methods).map{|s|s.to\_sym} > > \> if @@file\_methods.include? name > > \> if File.method(name).arity == 1 > > \> lambda{ File.send(name, @path) } > > \> elsif name == :truncate > > \> lambda{|len| File.send(name, @path, len) } > > \> elsif File.method(name).arity == 2 > > \> lambda{|path| File.send(name, @path, path) } > > \> end > > \> elsif @@dir\_methods.include? name > > \> # handle Dir methods here > > \> end > > \> end > > \> end > > \> > > \> The equivalent portion of code using 'def' would be much, much longer, > > \> and very repetitive. The equivalent code using method\_missing would be > > \> about the same length, but if anyone tried to check it's capabilities, > > \> it would seem to almost be an empty object. > > > > Although I agree to that - wouldn't it be more efficient to define all > > forwarding methods in DirectoryItem class once and for all? That way you > > get these benefits: > > > > - faster as methods can be invoked directly and no lambdas have to be > > created > > - reduced mem usage as not every instance has its own copy of the lambdas > > > > Drawback is of course that methods added to File and Dir later don't get > > invoked - but it's unlikely in this case I'd say. > > > > Also, a suggestion for improvement: wrap dynamic\_method with a method > > similar to this, which will reduce the number of created lambdas: > > > > # untested > > def dyn\_create(name) > >   m = dynamic\_method(name) > >   class\<\ >     define\_method(name.to\_sym,\*a,&m) > >   end > > end > > > > Then invoke this method via respond\_to?, method\_missing and method. Then > > the method is defined on first access. What do you think?