×
The Ruby and Rails community linklog
Made a library? Written a blog post? Found a useful tutorial? Share it with the Ruby community here or just enjoy what everyone else has found!
Made a library? Written a blog post? Found a useful tutorial? Share it with the Ruby community here or just enjoy what everyone else has found!
Comments
Seems to me you went to an awful lot of trouble just to end up with:
def do_tricks(&b) instance_eval(&b) end
Where did you stumble upon this Proc#bind_to method?
hi trans. i think it was here that i first found mention of it.
and yeah, definitely for the Dog example, binder is overkill. but if you’re developing a large DSL, with all kinds of methods rebinding blocks passed to them to all kinds of closures (not just self), then “bind :some_method, :some_closure” starts to look a little more appealing. or at least it did to me :-) thanks for commenting!
I’d suggest removing these aliases from Object. You want to be pretty restrained if you extend a core class, like Object. They almost seem specific to your dog example :)
alias_method :ask, :tell alias_method :teach, :tell alias_method :beg, :tellThanks for playing but next time review your code and think it through before you release it to the world. Modifying Object like you have is a really bad idea. Even worse are the aliased methods are not general but specific to your example.
yeah, good point, i’m removing the ask/teach/beg methods. i still like tell.
and to the anon troll: the aliased methods were certainly ill-advised (i was mad with power), but monkey-patching Object is valid in certain circumstances: if your intention is to create a new, pervasive language feature (or essentially, a new dialect), then yeah, monkey-patching Object is fair-game. if, however, you didn’t intend to pollute the namespace with what amounts to a new reserved word, but instead, to add some functionality that people can opt-in to, then definitely, monkey-patching Object is a bad idea.
Post a comment