On Sep 2, 2011, at 9:08 AM, Mikeal Rogers wrote:
> fibers turns node.js in to something the core team doesn't really view as
> being "node.js" any longer.
>
> 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.
Why do you believe that V8, supporting generators as spec'ed for ES6, embedded
in Node, should not allow people to write yield and explicitly give up
invariants?
/be
>
> -Mikeal
>
> On Sep 2, 2011, at September 2, 20118:58 AM, Dmitry Soshnikov wrote:
>
>> 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).
>>
>> 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.:
>>
>> Object.defineProperty(foo, "bar", {
>> get: function () {
>> var r = yield setTimeout(getBar, 1000);
>> return r;
>> };
>> });
>>
>> var x = 10;
>> var y = yield foo.bar + x;
>> // other code
>>
>> 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.
>>
>> Transformation on a source code at compile time (with replacing e.g. `wait
>> foo.bar` with a callback) seems very elegant solution.
>>
>> Dmitry.
>>
>> On 02.09.2011 19:46, Juan Ignacio Dopazo wrote:
>>>
>>> There is already a Node module that uses Proxies as a way of enforcing
>>> promises:
>>>
>>> https://github.com/sam-mccall/node-plate
>>>
>>> It allows your to write:
>>>
>>> var pfs = plate(fs);
>>> pfs.writeFile('/etc/passwd.bak', pfs.readFile('/etc/passwd'));
>>> pfs.end(function(err) { if(err) throw err; console.log("It's saved"); });
>>>
>>> Juan
>>>
>>> On Fri, Sep 2, 2011 at 12:02 PM, Xavier MONTILLET <[email protected]>
>>> wrote:
>>> Hi,
>>>
>>> I'm just a lambda JavaScript programmer who loves building black boxes
>>> with the smallest APIs possible and a couple of hours ago, I found out
>>> Proxys existed and since then, I've been watching talks and reading
>>> articles about them. And it sure looks awesome.
>>>
>>> But there's one thing I didn't get:
>>> Will we be able to use them to provide an API for remote objects?
>>>
>>> Because it looks it it can but it lacks the asynchronous aspect.
>>> This guys says it will:
>>> http://code.google.com/p/es-lab/wiki/Talks#Changes_to_ECMAScript,_Part_2:_Harmony_Highlights_-_proxies_and
>>> But when I look at the draf (
>>> http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy
>>> ), the only sentence I see "asynchronous" in is this one:
>>> "This example shows how to implement a proxy that represents an
>>> eventual reference, enforcing asynchronous property access on an
>>> object."
>>>
>>> And in the code below, the only thing that might do something
>>> asynchronous is this:
>>>
>>> get: function(receiver, name) {
>>> return promiseFor(function(){return obj[name];});
>>> },
>>>
>>> And it sounds more like it returns some value and *then* gets the real one.
>>> And this promiseFor function appears nowhere else on the page...
>>>
>>> And if it can not be asynchronous, it (probably) can't be used in
>>> Node.JS which, apart from the browser, will more likely become one of
>>> the most used JavaScript environment.
>>> But the thing is that if you provide both a synchronous and an
>>> asynchronous APIs, it might become a big mess...
>>> The the best solution seems to be to provide only an asynchronous API
>>> with a callback given as argument to get, set, has, hasOwn and so on.
>>>
>>> But then is gets quite strange because you do:
>>>
>>> var value = proxy.property;
>>>
>>> and it does
>>>
>>> var value = handler.get( proxy, 'property' );
>>>
>>> but if get is asynchronous this can not work...
>>> Or then it has to be some strange C++ code and we loose all the
>>> interest of having asynchronous requests in the first place.
>>>
>>> Thank you in advance for your potential future response.
>>>
>>> ------------------------------------------------------------
>>>
>>> To put it in a nutshell: Will Proxys support asynchronous requests?
>>>
>>> ------------------------------------------------------------
>>>
>>> If my question is dumb and / or pointless, I'm sorry for wasting your time.
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
