A long call chain...

Discussion in 'Ruby' started by Benjohn Barnes, Mar 21, 2006.

  1. 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
    Benjohn Barnes, Mar 21, 2006
    #1
    1. Advertising

  2. Benjohn Barnes

    Eric Hodel Guest

    On Mar 20, 2006, at 10:48 PM, Benjohn Barnes wrote:

    > 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


    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.

    > 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.


    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

    What do you want to use this for? Why?

    --
    Eric Hodel - - http://blog.segment7.net
    This implementation is HODEL-HASH-9600 compliant

    http://trackmap.robotcoop.com
    Eric Hodel, Mar 21, 2006
    #2
    1. Advertising

  3. Benjohn Barnes

    Guest

    This morning, I asked about using aliases and wrote:
    *snip*
    > 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?"


    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!
    , Mar 21, 2006
    #3
  4. On 21 Mar 2006, at 07:35, Eric Hodel wrote:

    > On Mar 20, 2006, at 10:48 PM, Benjohn Barnes wrote:
    >
    >> 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

    >
    > Yuck.


    :) Yeah, sorry about that.

    *snip*

    >> 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.

    >
    > 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
    Benjohn Barnes, Mar 23, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. George Marsaglia

    Assigning unsigned long to unsigned long long

    George Marsaglia, Jul 8, 2003, in forum: C Programming
    Replies:
    1
    Views:
    657
    Eric Sosman
    Jul 8, 2003
  2. Daniel Rudy

    unsigned long long int to long double

    Daniel Rudy, Sep 19, 2005, in forum: C Programming
    Replies:
    5
    Views:
    1,174
    Peter Shaggy Haywood
    Sep 20, 2005
  3. Mathieu Dutour

    long long and long

    Mathieu Dutour, Jul 17, 2007, in forum: C Programming
    Replies:
    4
    Views:
    457
    santosh
    Jul 24, 2007
  4. veryhotsausage
    Replies:
    1
    Views:
    1,773
    veryhotsausage
    Jul 4, 2008
  5. optimistx

    f = long.chain.of.identifiers.fun error?

    optimistx, Sep 30, 2009, in forum: Javascript
    Replies:
    21
    Views:
    188
Loading...

Share This Page