A long call chain...

B

Benjohn Barnes

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
 
E

Eric Hodel

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?
 
B

benjohn

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!
 
B

Benjohn Barnes

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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top