Hello Per,
On Wed, Nov 5, 2008 at 3:04 PM, Per Cederberg <[EMAIL PROTECTED]> wrote: > > I don't think I understand the use case where this type of thing would > come to use. Could you please provide a scenario? Is it useful in > libraries? Or widgets? Or webapps? It has happened to me to require registering an observer before the actual source of the signal was created. In these cases, I would just register the observer to listen to a given signal on any source. Later the relevant object would signal the right message and the observer would be triggered. Or, I need to update an object, whatever it happens to it. So I can register for any signal on that given object and trigger an action. > Otherwise, here is a quick review without much thought: > > 1. Using just "signal.apply" instead of "MochiKit.Signal.signal.apply" > causes problems if not exporting functions. Ok. No problem. > 2. It might be unexpected by users that connecting to anySource and > anySignal, will only receive signals that are manually sent via the > signal() function. I.e. not the DOM signals. Yep. This is a reasonable but other than the common API, DOM and non DOM signaling is managed so differently that I am not really sure it would be technically reasonable to do it. But this is definitely a question worth discussing deeper. > 3. The addition of these generic objects impose a penalty on all > manual signal sending, something which might not be desired. We should > probably look for minimizing the impact a bit here, I think. Correct. I think it could be possible to reduce the cost, at least until the new "broadcast" features are used for the first time. But here too there should be space for big improvements. At this point I was more interested in questioning the API "semantic" extension. > 4. The MochiKit.Signal.anySource and MochiKit.Signal.anySignal names > should perhaps be upper-case as they are constants. This makes sense; I had no clear option on this issue, and I am perfectly with upper-case too. > Also, for a user it might be clearer to use something like null or undefined > instead of > a constant from MochiKit.Signal. I think that passing null will make some of the current tests to fail. So in order to avoid changing the current behaviour, I have opted for a more explicit option; but I had thought about using nulls myself. > Anyway. These were just a couple of random thoughts. I'm all for > finding ways to make it even easier to work with signals and > especially deferreds. How do you see integration between signals and deferred? I am very interested in this, as our application make extensive use of both, and we are now thinking about removing our custom notification center in order to simplify all signaling code and settle for a single API, and we are going to consolidate on MochiKit.Signal. Best regards, Giulio Cesare --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MochiKit" group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~----------~----~----~----~------~----~------~--~---
