Comments on: Calling Grandparents in Ruby http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/ "...the three great virtues of a programmer: laziness, impatience, and hubris." -- Larry Wall Sun, 29 Aug 2010 18:46:09 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Avdi Grimm http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1000 Avdi Grimm Fri, 26 Feb 2010 00:52:55 +0000 http://avdi.org/devblog/?p=386#comment-1000 I don't think it's any more a hack than e.g. any code that uses #send to call a method. Verbose and non-obvious, maybe, but I think it's using language features for their intended purpose. I don't think it's any more a hack than e.g. any code that uses #send to call a method. Verbose and non-obvious, maybe, but I think it's using language features for their intended purpose.

]]> By: dkubb http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-999 dkubb Fri, 26 Feb 2010 00:37:50 +0000 http://avdi.org/devblog/?p=386#comment-999 I did not know this. I can think of a few (rare) cases where I did want access to the grant parent method so I aliased it in the parent class prior to defining the same named method in the parent. This always felt like a bit of a hack to me, and while your idea is still a hack, the intention is clearer.<br><br>This may also be useful in cases where the parent class is in a library you don't control, and you'd prefer not locally/monkey patch it. I did not know this. I can think of a few (rare) cases where I did want access to the grant parent method so I aliased it in the parent class prior to defining the same named method in the parent. This always felt like a bit of a hack to me, and while your idea is still a hack, the intention is clearer.

This may also be useful in cases where the parent class is in a library you don't control, and you'd prefer not locally/monkey patch it.

]]> By: Avdi Grimm http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1010 Avdi Grimm Thu, 25 Feb 2010 22:08:52 +0000 http://avdi.org/devblog/?p=386#comment-1010 True. This is more of an issue for the case were you're merely calling it and not overriding it (not shown). True. This is more of an issue for the case were you're merely calling it and not overriding it (not shown).

]]> By: Tommy Morgan http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1009 Tommy Morgan Thu, 25 Feb 2010 22:05:44 +0000 http://avdi.org/devblog/?p=386#comment-1009 If you're overriding #foo in Child anyway, then you're already preventing that. If you're overriding #foo in Child anyway, then you're already preventing that.

]]> By: Avdi Grimm http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1008 Avdi Grimm Thu, 25 Feb 2010 22:01:10 +0000 http://avdi.org/devblog/?p=386#comment-1008 The problem here is that Interloper itself might use its own #foo method in other (desirable) Interloper methods. The problem here is that Interloper itself might use its own #foo method in other (desirable) Interloper methods.

]]> By: Tommy Morgan http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1005 Tommy Morgan Thu, 25 Feb 2010 21:51:47 +0000 http://avdi.org/devblog/?p=386#comment-1005 Now *that* is a more interesting and less scary use case. :) Now *that* is a more interesting and less scary use case. :)

]]> By: Tommy Morgan http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1007 Tommy Morgan Thu, 25 Feb 2010 21:43:35 +0000 http://avdi.org/devblog/?p=386#comment-1007 It seems that allowing an unrelated module to override methods that just happen to be named the same is prone to breaking things as well, so I think by the time you're doing that you have to accept that it's going to be a bit tricky for any future maintainers to figure out what's going on. But you're right, on reflection, the alias method is unnecessarily fragile.<br>Perhaps it would be best then, if we're not using Interloper#foo at all? That's what bothers me about this anyway, so perhaps this would be a better solution:<br><a href="http://gist.github.com/314707" rel="nofollow">http://gist.github.com/314707</a> It seems that allowing an unrelated module to override methods that just happen to be named the same is prone to breaking things as well, so I think by the time you're doing that you have to accept that it's going to be a bit tricky for any future maintainers to figure out what's going on. But you're right, on reflection, the alias method is unnecessarily fragile.
Perhaps it would be best then, if we're not using Interloper#foo at all? That's what bothers me about this anyway, so perhaps this would be a better solution:
http://gist.github.com/314707

]]> By: Avdi Grimm http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1004 Avdi Grimm Thu, 25 Feb 2010 21:31:39 +0000 http://avdi.org/devblog/?p=386#comment-1004 ...not to mention that it's not usable if you're trying to define a method in a module. For instance, the case where you're writing a module which uses built-in Object methods like #send or #hash and needs to make sure the calls don't get diverted to some other intervening definition of #send or #hash, no matter where it is included. …not to mention that it's not usable if you're trying to define a method in a module. For instance, the case where you're writing a module which uses built-in Object methods like #send or #hash and needs to make sure the calls don't get diverted to some other intervening definition of #send or #hash, no matter where it is included.

]]> By: Avdi Grimm http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1006 Avdi Grimm Thu, 25 Feb 2010 21:26:28 +0000 http://avdi.org/devblog/?p=386#comment-1006 I personally find that solution less elegant, and I don't like the fact that simply moving things around in the class definition could break it. It's fragile in ways that could be very nonobvious to a future maintainer. Using method binding is unambiguous as to which version of the method you want.<br><br>YMMV, of course. I personally find that solution less elegant, and I don't like the fact that simply moving things around in the class definition could break it. It's fragile in ways that could be very nonobvious to a future maintainer. Using method binding is unambiguous as to which version of the method you want.

YMMV, of course.

]]> By: Tommy Morgan http://avdi.org/devblog/2010/02/25/calling-grandparents-in-ruby/comment-page-1/#comment-1003 Tommy Morgan Thu, 25 Feb 2010 21:19:00 +0000 http://avdi.org/devblog/?p=386#comment-1003 Wouldn't it be better to alias the parent method before including the module in that case? Or is there a circumstance I'm missing here?<br><a href="http://gist.github.com/314681" rel="nofollow">http://gist.github.com/314681</a> Wouldn't it be better to alias the parent method before including the module in that case? Or is there a circumstance I'm missing here?
http://gist.github.com/314681

]]>