On Sep 2, 2011, at 1:45 PM, Mikeal Rogers wrote:
> We have no control over what v8 adds or what happens in Harmony.
>
> We do have control over what we use in node.js core and the patterns we drive
> forward in the community.
>
> We already don't use a lot of the features in the language and we're happy
> with that.
Yeah, but I'm not asking what. I'm asking why.
Beliefs if they are rational can be explained. Why is a callback parameter
supplied with a function expression actual the only or best way to delimit when
invariants can vary due to event loop concurrency? Why isn't yield *actually
better*?
Maybe you need to try yield to say more. It's hard to believe the answer is
just "because we're used to callbacks". So what' s the deeper reason?
As you heard on that NodeConf panel, people to balk at the function expression
nesting. Ryan and I both agreed it's an issue. Not the most important, but not
zero either.
/be
>
> -Mikeal
>
> On Sep 2, 2011, at September 2, 20111:34 PM, Brendan Eich wrote:
>
>> 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
