 |
lua-l archive |
|
|
||
|
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/issuesOn 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.