<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>fibers turns node.js in to something the core team doesn't really view as being "node.js" any longer.</div><div><br></div><div>we believe that it's more important to have assurances that your state can't mutate between anything but a callback and that breaking that means you're basically breaking node.</div><div><br></div><div>-Mikeal</div><br><div><div>On Sep 2, 2011, at September 2, 20118:58 AM, Dmitry Soshnikov wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">

  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
    <title></title>
  
  <div text="#000000" bgcolor="#ffffff">
    Besides, IIRC, there is a module for Node called node-fibers, which
    introduces possibility of `yiled` for V8 (though, the implementation
    differs from (standard) `yield` from SpiderMonkey).<br>
    <br>
    And for the topic starter -- in ES6 it's planned to standardize
    `yield` feature which will allow to have asynchronous programming in
    the synchronous style. Regarding proxies (and actually just simple
    getters) you may use just a prefix `yield` which suspends the
    control execution until the asyncronious result will be ready, and
    then continuous the execution. E.g.:<br>
    <br>
    Object.defineProperty(foo, "bar", {<br>
      get: function () {<br>
        var r = yield setTimeout(getBar, 1000);<br>
        return r;<br>
      };<br>
    });<br>
    <br>
    var x = 10;<br>
    var y = yield foo.bar + x;<br>
    // other code<br>
    <br>
    But, I think some less verbose syntactic construct than manual
    `yield` every time (with wrapping all this in a special "task")
    would be nice to have.<br>
    <br>
    Transformation on a source code at compile time (with replacing e.g.
    `wait foo.bar` with a callback) seems very elegant solution.<br>
    <br>
    Dmitry.<br>
    <br>
    On 02.09.2011 19:46, Juan Ignacio Dopazo wrote:
    <blockquote cite="mid:CA+ejddU1f1C8NxJq+adCcC2KGCAgm6T51MdzDyU9AUQ1N-RYAg@mail.gmail.com" type="cite">There is already a Node module that uses Proxies as a
      way of enforcing promises:
      <div><br>
      </div>
      <div><a moz-do-not-send="true" href="https://github.com/sam-mccall/node-plate">https://github.com/sam-mccall/node-plate</a></div>
      <div><br>
      </div>
      <div>It allows your to write:</div>
      <div><br>
      </div>
      <font class="Apple-style-span" face="'courier new', monospace">var
        pfs = plate(fs);<br>
        pfs.writeFile('/etc/passwd.bak', pfs.readFile('/etc/passwd'));<br>
        pfs.end(function(err) { if(err) throw err; console.log("It's
        saved"); });</font>
      <div>
        <br>
      </div>
      <div>Juan<br>
        <br>
        <div class="gmail_quote">On Fri, Sep 2, 2011 at 12:02 PM, Xavier
          MONTILLET <span dir="ltr"><<a moz-do-not-send="true" href="mailto:xavierm02.net@gmail.com">xavierm02.net@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
            0.8ex; border-left: 1px solid rgb(204, 204, 204);
            padding-left: 1ex;">
            Hi,<br>
            <br>
            I'm just a lambda JavaScript programmer who loves building
            black boxes<br>
            with the smallest APIs possible and a couple of hours ago, I
            found out<br>
            Proxys existed and since then, I've been watching talks and
            reading<br>
            articles about them. And it sure looks awesome.<br>
            <br>
            But there's one thing I didn't get:<br>
            Will we be able to use them to provide an API for remote
            objects?<br>
            <br>
            Because it looks it it can but it lacks the asynchronous
            aspect.<br>
            This guys says it will:<br>
            <a moz-do-not-send="true" href="http://code.google.com/p/es-lab/wiki/Talks#Changes_to_ECMAScript,_Part_2:_Harmony_Highlights_-_proxies_and" target="_blank">http://code.google.com/p/es-lab/wiki/Talks#Changes_to_ECMAScript,_Part_2:_Harmony_Highlights_-_proxies_and</a><br>
            But when I look at the draf (<br>
            <a moz-do-not-send="true" href="http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy" target="_blank">http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy</a><br>
            ), the only sentence I see "asynchronous" in is this one:<br>
            "This example shows how to implement a proxy that represents
            an<br>
            eventual reference, enforcing asynchronous property access
            on an<br>
            object."<br>
            <br>
            And in the code below, the only thing that might do
            something<br>
            asynchronous is this:<br>
            <br>
            get: function(receiver, name) {<br>
                return promiseFor(function(){return obj[name];});<br>
              },<br>
            <br>
            And it sounds more like it returns some value and *then*
            gets the real one.<br>
            And this promiseFor function appears nowhere else on the
            page...<br>
            <br>
            And if it can not be asynchronous, it (probably) can't be
            used in<br>
            Node.JS which, apart from the browser, will more likely
            become one of<br>
            the most used JavaScript environment.<br>
            But the thing is that if you provide both a synchronous and
            an<br>
            asynchronous APIs, it might become a big mess...<br>
            The the best solution seems to be to provide only an
            asynchronous API<br>
            with a callback given as argument to get, set, has, hasOwn
            and so on.<br>
            <br>
            But then is gets quite strange because you do:<br>
            <br>
            var value = proxy.property;<br>
            <br>
            and it does<br>
            <br>
            var value = handler.get( proxy, 'property' );<br>
            <br>
            but if get is asynchronous this can not work...<br>
            Or then it has to be some strange C++ code and we loose all
            the<br>
            interest of having asynchronous requests in the first place.<br>
            <br>
            Thank you in advance for your potential future response.<br>
            <br>
            ------------------------------------------------------------<br>
            <br>
            To put it in a nutshell: Will Proxys support asynchronous
            requests?<br>
            <br>
            ------------------------------------------------------------<br>
            <br>
            If my question is dumb and / or pointless, I'm sorry for
            wasting your time.<br>
            _______________________________________________<br>
            es-discuss mailing list<br>
            <a moz-do-not-send="true" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
            <a moz-do-not-send="true" href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
es-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/es-discuss">https://mail.mozilla.org/listinfo/es-discuss</a>
</pre>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>https://mail.mozilla.org/listinfo/es-discuss<br></blockquote></div><br></body></html>