A Harmony Proxy looks like an object. When ANY member is accessed, you have a function called that returns (or sets) the value. Sort of like a wildcard getter and setter for the object in question. There was mention a while ago about being able to proxy for the global or window object. I am not sure if that's possible at this point.
I created a github repo a while ago with some experiments using proxies: https://github.com/mschwartz/SilkJS-Harmony And the ultimate writeup (perhaps! :): http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies On Mar 13, 2013, at 8:44 AM, Benjamin Kalman <[email protected]> wrote: > Thanks for the responses, very interesting. > > On Wed, Mar 13, 2013 at 3:01 AM, Jakob Kummerow <[email protected]> > wrote: > Welcome to JavaScript! Have you considered using a language with a sane > specification? > > Well, the other option is to try to write everything through the v8 API, > which would be quite a bit of effort - we have 5000 non-whitespace/comment > lines of JS, and ideally we don't want to rewrite it all. If we can come up > with an easier-to-write DSL around the v8 API then that might be more viable, > but I haven't put a lot of thought into that. > > A detail that doesn't really concern v8: for things like > document.createElement we need DOM APIs which the separate-context solution > won't actually work easily without changes to webkit afaik. It also makes the > write-in-C++ solution harder for similar reasons, we'd need to make sure > every DOM API we ever call is available from chromium. > > > Have you tried benchmarking it? If you can't measure it, it's not important. > If you can, you'll have data to help decide whether the difference is a > problem in your use case or not. > > > Not really, we don't have any meaningful perf testing for extensions. I could > try profiling I guess. A data point is that yesterday I found a context we > were creating unnecessarily and fixed it, and it doesn't seem to have made > any difference to page load speed (which is on the order of 500ms). This is > promising. > > Alternatively, apparently v8 has solved this problem internally by > guaranteeing that it's running the builtin libraries - is/can this be exposed? > > Sorry, no. > You can lobby for an official way to retrieve the original unpatched > implementations to be included in ECMAScript 7. The general problem with > introducing sanity, however, is that you can't break existing code, which > basically means that all the good stuff has to be opt-in, which in turn means > that the original problem doesn't just go away, instead you'll still have to > support it until it slowly dies out, if ever. > > > Getting into the world of ESFoo isn't really where I want to go with this. > Strawman: if there were a 'use strict' for builtins, like 'use builtins', > where for that file you get unpolluted APIs, that might solve our problems. > However, I can see this breaking e.g. if I pass an array from one file to > another, should it be 'instanceof Array'? > > I guess what I was realistically asking about is some support at the v8 API > level. > > Crazy idea: how about a rule for the Chrome web store that forbids > monkey-patching builtins? :-) > > Not really feasible, monkey patching is an idiom that JS developers would get > very upset about being taken away from them. Plus lots of libraries do it. We > had a hard enough problem (and in fact failed) forbidding eval. And likewise > freezing globals etc. Philosophically it's just sad if we forbid existing > features of a platform because it's too hard to implement. > > Lastly - I am not really sure about how harmony proxies work, but it sounds > like we're told after they change not before they change? If not, that would > certainly be a neater solution than what we're doing for JSON (saving > function references on load), but I can see it getting messy with prototypes. > > Cheers, > Ben. > > -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
