On Wed, Jan 13, 2010 at 6:01 PM, Doug Rogers
<doug.rogers@elbitsystems-us.com> wrote:
Doug Rogers wrote:
> I like the signal:stop() idea. I usually use return values to stop
> further processing. Your way is more explicit.
On further review I noticed that the signal is not passed to the
handler. I think it would be better if the signal were always the first
parameter to the handler. Otherwise the handler can only be used with a
single globally accessible signal.
We thought about that, but we found to be better to not obligate the handler to receive a signal when you simply does not want the signal being passed to the handler, we wanted to maintain the handler functions 100% like the user of the API wants. If you want the signal object inside your handler function you can use closures. At least that was our idea, because we thought about that, since GSignal does like you said, the first parameter is the object that emitted, but we wanted to give more flexibility and make use of closures instead of obligating the user to always receive a signal object on his handler even when he don't want one.
Also, the 'test' link at http://wiki.github.com/katcipis/Luanotify/api
after Signal Class should be updated to match the new name
(test_signal.lua).
Thanks, I'm going to fix it.
Thanks for taking time to actually read the code and comment it Doug, all the other changes you proposed are interesting...I'm going to create issues on github with them, so i can discuss them with others collaborators (right now is just one :-)) and thought them through.
Best regards,
Katcipis
