On Sat, Mar 19, 2011 at 10:57 AM, David Bruant <span dir="ltr"><<a href="mailto:david.bruant@labri.fr">david.bruant@labri.fr</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  
    
  
  <div text="#000000" bgcolor="#ffffff">
    Le 19/03/2011 17:58, Mark S. Miller a écrit :
    <blockquote type="cite"><div class="gmail_quote"><div class="im"><div>[...] The two things I'd fix in this lower layer
          abstraction:</div>
        <div><br>
        </div>
        <div>* No clamping. Time runs as fast as the platform lets it
          run.</div>
        <div>* The return value is not an integer but a unique
          unforgeable object for canceling the event. No one without
          that object can cancel that event.</div>
      </div></div>
    </blockquote>
    This last point is something I was about to raise when starting to
    think about extending the Q API.<br>
    setTimeout returns a number, so a malicious could loop through
    numbers and call clearTimeout on them. An unforgeable object sounds
    like the correct response to this issue. Have you considered
    wrapping setTimeout&friends in SES with this solution? It
    wouldn't break code which do not rely on the returned value being a
    number (but would break code which does, of course).</div></blockquote><div><br></div><div>Caja does exactly this. So far we haven't found any code that this actually breaks. All uses we've encountered[1] treat the return value of setTimeout/setInterval as simply something they can remember and later pass to clearTimeout/clearInterval. </div>
<div><br></div><div>[1] That I'm aware of. Caja users should speak up if they've hit a counter-example. Or anyone else that has seen code in the wild that actually counts on these values being numbers.</div><meta charset="utf-8"><div>
<br></div><div>I actually haven't thought about this in the context of SES, and I must. Thanks for raising this.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff"> I think there
    would be a need to wrapped the passed callback in order to achieve
    garbage collection.<br></div></blockquote><div><br></div><div>I didn't understand that. Could you expand? Thanks.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
    <br>
    I agree on the rest you've said except one thing: I'm not really
    sure ES should standardized the 4ms clamping. It is a reality in web
    browsers and maybe fair for the WHATWG to standardize it as such for
    web backward compatibility, but maybe that other non-web browser
    ES-based implementations do not follow this 4ms restriction. Any
    idea if there is a 4ms clamping in node.js setTimeout? Or in other
    ES-based implementations?<br>
    If there is none, the ECMAScript spec could just leave some room to
    implementation-dependent behaviors.<br></div></blockquote><div><br></div><div>I like this approach. Does anyone know of any problems leaving the 4ms issue as dependent on the hosting environment, and not to be standardized as part of an ES setTimeout/setInterval standard?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff">
    <br>
    <br>
    After giving it further thought, here are the ideas I've had on
    adding time to the Q API:<br>
    Q.when(timedPromise, success); would be a nice syntax to call a
    'success' function when the promise is resolved.<br></div></blockquote><div><br></div><div>I don't understand. Given that timedPromise is the kind of thing that delay() returns, just doing a Q.when() on a timePromise as above will already do the right thing. That's why the delay() and race() abstractions compose so nicely -- because race() does a Q.when on the promise returned by delay().</div>
<div><br></div><div>I suspect I'm misunderstanding you. I'll wait for clarification on this point before proceeding with the rest. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
    <br>
    To reject a timedDefered, something like:
    timedDeferred.resolve(Q.reject('')) could do it. But it requires
    providing the resolver to the timedDeferred creator. I do not know
    if it's a good idea to provide the resolver to user script since, in
    the way I see it, the resolver should exclusively be given to the
    engine which has the responsibility to manage time. I may be wrong.
    It however could be an occasion to trigger a promise resolution in
    advance.<br>
    In Kris Kowal Q implementation (my (untouched) fork
    <a href="https://github.com/DavidBruant/q/blob/master/lib/q.js#L135" target="_blank">https://github.com/DavidBruant/q/blob/master/lib/q.js#L135</a>),
    'reject' is provided as part of the promise if I understand well.
    Providing the rejecter but not the resolver could be a way to solve
    the second use case without providing the resolver to the user
    script.<br>
    Do people have opinions on the resolver being provided or not to the
    user in case of a timed defered?<br>
    <br>
    Something that could be convenient in the timedPromise/Deferred
    construtor would be to be allowed to pass a Date object. If I want a
    promise to be resolved when my next birthday happens, I would prefer
    to write Q.timedDefer( Date(2012, 3, 8, 12) ) instead of computing
    milliseconds since 1/1/70. A decision would have to be made for
    dates in the past (actually, for negative number of milliseconds
    too)<br>
    <br>
    On the constructor itself, maybe an optional argument could be given
    to Q.defer. Maybe it would be better to have a Q.timedDefer
    function. These are just ideas. I have no strong opinion.<br>
    <br>
    David<br>
  </div>

</blockquote></div><br><br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>