Discuss
  • Harmony - proxies | asynchronous

Harmony - proxies | asynchronous

# Xavier MONTILLET (14 years ago)

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: code.google.com/p/es-lab/wiki/Talks#Changes_to_ECMAScript,_Part_2:Harmony_Highlights-_proxies_and But when I look at the draf ( 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.

# Mikeal Rogers (14 years ago)

We've talked about the problems that would come from this a lot in node.js.

One of the best comments I thought was from Jeremy Ashkenas (creator of coffeescript).

groups.google.com/group/nodejs/browse_thread/thread/c334947643c80968/9533c06d486c10e6?lnk=gst&q=jashkenas#9533c06d486c10e6

# Juan Ignacio Dopazo (14 years ago)

There is already a Node module that uses Proxies as a way of enforcing promises:

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

# Dmitry Soshnikov (14 years ago)

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.

# Mikeal Rogers (14 years ago)

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.

# Brendan Eich (14 years ago)

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?

# Mikeal Rogers (14 years ago)

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.

# Brendan Eich (14 years ago)

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.

# Jorge (14 years ago)

On 02/09/2011, at 18:08, 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.

But fibers don't break that guarantee (if it exists at all: contexts are not immutable, even without fibers).

# Dean Landolt (14 years ago)

On Sat, Sep 3, 2011 at 7:15 AM, Jorge <jorge at jorgechamorro.com> wrote:

On 02/09/2011, at 18:08, 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.

But fibers don't break that guarantee (if it exists at all: contexts are not immutable, even without fibers).

A wait construct does. But what I think Mikeal misunderstands is that generators aren't fibers, and wait, at least as it exists in something like fiber.js, is not explicitly possible. IIUC the invariant he's concerned about isn't actually broken.

# Brendan Eich (14 years ago)

On Sep 3, 2011, at 12:19 PM, Dean Landolt wrote:

On Sat, Sep 3, 2011 at 7:15 AM, Jorge <jorge at jorgechamorro.com> wrote: On 02/09/2011, at 18:08, 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.

But fibers don't break that guarantee (if it exists at all: contexts are not immutable, even without fibers).

A wait construct does. But what I think Mikeal misunderstands is that generators aren't fibers, and wait, at least as it exists in something like fiber.js, is not explicitly possible. IIUC the invariant he's concerned about isn't actually broken.

That's right. Generators do not make it possible for a function foo calling bar() directly, without using yield explicitly, to lose its invariants. I've been over this with Mikeal before, but perhaps on Twitter (which isn't the best place for talking about things like invariants ;-).