The Signal class is done and using an set implementation that is more efficient than the other table.insert / remove method.
The order of call on the post_emit functions call has been reversed as have been suggested, now the pre-emits are called on a queue behaviour and post-emits are called on a stack behavior.
Now I'm thinking on implementing an event notification system using this signal implementation, but it will connect/disconnect/block/etc on names, not on signal instances, and it will be hierarchic.
Something like
notify.connect("mouse", function1)
notify.connect("mouse::left_click", function2)
when an "mouse" event is emitted, only function1 is called, but when a "mouse::left_click" is emitted, function1 and function2 are called.
the notify is the module and instead of using instances to emit the signals, you use the names. Name clashing can be resolved with the hierarchic system, and it will be easier to communicate with different parts of the software.
i know none of this implementations are complicated, to tell the truth they are quite easy to implement :-). But i liked the suggestions i received and i didn't found nothing quite like that already done on lua (without having to extract code from some project and fixing it to work on mine). I'm doing this to use on a project of my own, but i like to share.
Any suggestion are welcome, as soon as it gets done ill try to put it on luarocks.
Project page:
best regards,
Katcipis
On Thu, Jan 14, 2010 at 5:42 PM, Tiago Katcipis
<tiagokatcipis@gmail.com> wrote:
Just to inform that we moved the project to:
http://github.com/katcipis/luanotify
The uppercase L was not quite right :-).
We implemented some of the proposed changes too.
On Thu, Jan 14, 2010 at 3:05 PM, Tiago Katcipis
<tiagokatcipis@gmail.com> wrote:
On Wed, Jan 13, 2010 at 8:02 PM, Tiago Katcipis
<tiagokatcipis@gmail.com> wrote:
I created some issues with your ideas:
http://github.com/katcipis/Luanotify/issues
On Wed, Jan 13, 2010 at 5:40 PM, Doug Rogers
<doug.rogers@elbitsystems-us.com> wrote:
It might be better to run the tear_down functions in the opposite order
from the set_up functions, so they operate more like a stack. That way
the tear_down can undo any effects of its associated set_up for the next
(previous!) tear_down.
That make sense if you think of them as a push/pop or encode/decode
pair. If so, then it might be better to register the set_up and
tear_down functions as a pair (or add that as a separate call). But
think about the common use cases for set_up/tear_down.
This idea i didn't understood completely, why is there a relationship between the order of the set_up and tear_down calls?
i have give some thought on that with some help from Paulo and now i realize the case that you are talking about, since the stack behavior on the tear_down does not disturbs someone that is not interested on the call the tear_downs are called (which was my case, i was thinking on them not having a relationship) i think that will not be a problem to implement. So the set_up will have a FIFO behaviour and the tear_down a LIFO behavior. But we are still thinking on the possibility of allowing the user to define the behavior of the tear_down (switching between FIFO or LIFO), but i think its best to be LIFO only.
the idea is, before handling all events i open a resource....after all handlers have been called...i close the resources, i cant find an example where there is a relationship between the order the set_up and the tear_down is called, that's why we implemented a simple FIFO policy on both.
we thought that would be better to allow someone to define only tear down or only set_up...or both... independent from the common use cases, we wanted to give flexibility to the user, but maybe if you explain better the need of this syncronism between the set_up and the tear_down call it makes more sense to me.
As a final option, you might just want to let the signal itself define
set_up() and tear_down() and only call them if present:
function Signal:emit(...)
self.signal_stopped = false;
if self.set_up then
self.set_up()
end
for _, handler_table in ipairs(self.handlers) do
if(self.signal_stopped) then break end
if(handler_table.block == 0) then
handler_table.handler(...)
end
end
if self.tear_down then
self.tear_down()
end
end
The down side is that there would be only one of each (do you really
need multiples? can't the object take care of chaining them if necessary?).
well independent of my needs, i cant presume what will the user need, and why support only one set_up if i can support only one AND many if the user require? i think it is better to allow the user to decide that instead of obligating to have only one (since it is so simple to support more than one).
Almost all changes you proposed are great and we are going to implement it, thanks for the help.
