

Techniques for Duck Typing Ruby's Core Objects - sandal
http://blog.rubybestpractices.com/posts/gregory/007-rubyish-code.html

======
aaronblohowiak
Title is misleading. What I see presented in the article is a single
technique, "implement the same interface." What I expected instead was to see
methods for getting ruby core objects to present themselves as more complex
objects or so on. In that case, I'd expect to see references to
SimpleDelegate, Forwardable, duping the metaclass, extending the singleton
class of the instantiated objects and so forth.

~~~
sandal
I don't know how to edit titles on HN, otherwise I'd change it to "A Technique
For ..."

As for the rest of the ideas here, they're all good, and if you want to write
up a post about them, I'd be happy to run it on RBP Blog. We'll be opening up
third party contributions soon anyway. Or if you post somewhere else, I can
link this post back to it.

While delegation is interesting on its own, it isn't _too_ interesting when it
comes to duck typing in the abstract sense because it by definition chains you
to implementation details. Of course, it is nice to make an array-like thing
act like an array by just delegating the relevant calls, or something similar.

Of course, things _do_ get more exciting when you do something like this:

    
    
      a = [1,2,3]
      a.extend(ActLikeAFoo)
      expect_a_foo(a)
    

So thanks for pointing this out. It's a great technique for certain needs and
hopefully it'll get coverage soon on the blog.

~~~
aaronblohowiak
I'd be happy to help, please drop a line to aaron.blohowiak@gmail.com so I can
follow up with you.

~~~
sandal
email sent, thanks.

