# A long call chain **URL:** \ **Category:** Ruby\ **Created:** [March 21, 2006, 7:48am UTC](https://www.ruby-forum.com/t/a-long-call-chain/55455 "2006-03-21T07:48:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Benjohn\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e5b9ba/32.png) [@Benjohn\_B](https://www.ruby-forum.com/u/Benjohn_B)\ **Post date:** [March 21, 2006, 7:48am UTC](https://www.ruby-forum.com/t/a-long-call-chain/55455/1 "2006-03-21T07:48:23Z")
Hello everyone. I’m hoping to do something like this (and then automate it up by putting something neat in to a mix in module)… class Test def xxx; [1]; end alias xxx\_old xxx def xxx; xxx\_old + [2]; end alias xxx\_old xxx def xxx; xxx\_old + [3]; end alias xxx\_old xxx … end In real use, these various defs and aliases would be in different files, but would often be putting things in to the same class. The above doesn’t work - I think it’s leading to a non terminating recursive function. My first question is, “is it correct that this doesn’t work?” I’d like to use a mechanism like this to enable me to have a kind of hookable function in a class. As I said, the alias process would be encapsulated by waving my hands and working that out later, but probably making use of method\_defined. The mechanism allows you to build up an event handler: you send an event to a class instance, and any receivers that are registered for that event (by having defined the method to pick it up) will get it. Example hookable methods for my system will be: is\_being\_setup, will\_be\_torn\_down, has\_recieved\_message will\_send\_message. It’s worth noting that the will\_be methods should probably be executed in the reverse order from that in which they are defined! I’m pretty sure this is a good plan, but… Question: “Does this seem like a good plan?” Finally, as this doesn’t work, can you see a nicer way to implement it? I think I could capture the function each time it gets defined, and put it in to class state, but it would need to be per class, I think, rather than just on in the base class. I’ve thought about several variations, but none of them seem to be very nice at all. Thank you for any thoughts you have, Cheers, Benjohn ---
**Author:** ![Benjohn\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e5b9ba/32.png) [@Benjohn\_B](https://www.ruby-forum.com/u/Benjohn_B)\ **Post date:** [March 21, 2006, 8:35am UTC](https://www.ruby-forum.com/t/a-long-call-chain/55455/2 "2006-03-21T08:35:40Z")
On Mar 20, 2006, at 10:48 PM, Benjohn B. wrote: > … > end Yuck. > In real use, these various defs and aliases would be in different > files, but would often be putting things in to the same class. The > above doesn’t work - I think it’s leading to a non terminating > recursive function. > > My first question is, “is it correct that this doesn’t work?” The fact that this is unmaintainably difficult to do is a very, very big clue. Note also that this will break if you change the order of require, not good. > will\_send\_message. > observer.rb provides something similar to what you want, event > notification. > It’s worth noting that the will\_be methods should probably be > executed in the reverse order from that in which they are defined! > > I’m pretty sure this is a good plan, but… > > Question: “Does this seem like a good plan?” Not with random aliasing it doesn’t. > Finally, as this doesn’t work, can you see a nicer way to implement > it? I think I could capture the function each time it gets defined, > and put it in to class state, but it would need to be per class, I > think, rather than just on in the base class. I’ve thought about > several variations, but none of them seem to be very nice at all. Check out MuffDaddy: [http://blog.zenspider.com/archives/2005/02/muffdaddy\_the\_u.html](http://blog.zenspider.com/archives/2005/02/muffdaddy_the_u.html) What do you want to use this for? Why? – Eric H. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net) This implementation is HODEL-HASH-9600 compliant [http://trackmap.robotcoop.com](http://trackmap.robotcoop.com) ---
**Author:** ![Benjohn\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e5b9ba/32.png) [@Benjohn\_B](https://www.ruby-forum.com/u/Benjohn_B)\ **Post date:** [March 21, 2006, 10:22am UTC](https://www.ruby-forum.com/t/a-long-call-chain/55455/3 "2006-03-21T10:22:58Z")
This morning, I asked about using aliases and wrote: _snip_ > It’s worth noting that the will\_be methods should probably be > executed in the reverse order from that in which they are defined! > > I’m pretty sure this is a good plan, but… > > Question: “Does this seem like a good plan?” Well, I still think the idea in general is good, but I’ve really gone off the interface I was proposing. I think it’s going to be hard to implement anyway, and it’s a bit unexpected to def a method, but have really odd behaviour happen for no obviously visible reason… > Finally, as this doesn’t work, can you see a nicer way to implement > it? I think I could capture the function each time it gets defined, > and put it in to class state, but it would need to be per class, I > think, rather than just on in the base class. I’ve thought about > several variations, but none of them seem to be very nice at all. The train on the way here got me thinking of another way. I now think a good approach is to add a module method “add\_to\_hook” that can be used thus: class Blah include Hook def this\_should\_happen\_on\_hook\_start\_up; end def this\_should\_also\_happen\_on\_hook\_start\_up; end add\_to\_hool :start\_up, :this\_should\_happen\_on\_hook\_start\_up, :this\_should\_also\_happen\_on\_hook\_start\_up end And also add instance methods to support: Blah.new.call\_hook( :start\_up ) Blah.new.call\_hook\_backwards( :tear\_down ) The methods call\_hook and call\_hook\_backwards will look for hooks added in the receiver’s class, and also it’s superclasses (I’m going to leave out any included modules for now, but I think that would also be fine). The methods to be called will be despatched to as “normal” using the instance method send. This allows them to be overidden in the normal way, which could be useful. I’ve got some tests on my laptop, and the start of an implementation (doesn’t do any looking in the superclass yet); I’ll post them up, but can’t do so from work because of security paranoia 🙂 Two further things though: - I don’t like the name “hook” much, because there are lots of hooks in to a hookable, really. Which is verging on being decidedly HP Lovecraft. But “event” and “snooper” just sound weak. - TDD rocks! ---
**Author:** ![Benjohn\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/e5b9ba/32.png) [@Benjohn\_B](https://www.ruby-forum.com/u/Benjohn_B)\ **Post date:** [March 23, 2006, 11:59pm UTC](https://www.ruby-forum.com/t/a-long-call-chain/55455/4 "2006-03-23T23:59:19Z")
On 21 Mar 2006, at 07:35, Eric H. wrote: > > def xxx; xxx\_old + [3]; end > > alias xxx\_old xxx > > … > > end > > Yuck. 🙂 Yeah, sorry about that. _snip_ > > will\_send\_message. > > observer.rb provides something similar to what you want, event > notification. _nods_ It’s extremely close to the observer pattern. I wanted to build a very modular, and very easy to extend application. I was trying to use Ruby’s open classes to pull lots of extra things in to a class. What I noticed was that generally, the observers of a message sent by an object x, were in fact other parts of the object x. I was hoping to make use of this fact to avoid needing to subscribe things to a broadcaster. However, I’m pretty sure now that I was going in a bad direction, and instead, these bolt on / plug in features should be a system of collaborating objects, rather than a monolithic whole. This will also make subsystems much more testable too, I think. What I’d like though, is to avoid needing to unnecessarily describe how things should get stitched together. Anyway - I’ve just seen mention of Needle in the ruby quiz summary. It sounds distinctly close to the kind of things I’m thinking about, and the gem’s just finished pulling itself down, so I’ll go and have a look. Cheers, Benjohn