Re: Proxies and preventExtensions: how to avoid inconsistency in a membrane?

Hi Alex, The problems you are seeing are inherent to what you're trying to achieve. You're trying to build an abstraction (virtual extension properties that should continue to work even on non-extensible objects) that are directly in conflict with ES's invariants (e.g. if the object is truly

Re: The Invariants of the Essential Methods are false in case of reentrancy

I don't think it's too worrisome because of the following reasoning: Any code prior to the first invocation of obj.x (let's call this the "outer code") will have observed the property as configurable & writable, so having obj.x evaluate to 1 is a valid outcome. Any code that runs synchronously

Re: Object.freezing proxies should freeze or throw?

Thanks Claude for your careful review, and for trying to articulate a more general principle behind the invariant checks. The lack of such crisp principles makes it (too) difficult to verify whether all necessary checks are in place. To clarify, in the case of "update" MOP operations such as

Re: Object.freezing proxies should freeze or throw?

I just realized: since the tightened test is reading Desc.[[Writable]] but Desc can by any descriptor, we probably need to first check whether Desc is a DataDescriptor and disregard the writability test otherwise. 2016-08-08 22:35 GMT+02:00 Tom Van Cutsem <tomvc...@gmail.com>: >

Re: Object.freezing proxies should freeze or throw?

Claude's additional example is indeed evidence that Object.freeze is not to blame, but rather that the invariant checks of [[GetOwnPropertyDescriptor]] and [[DefineOwnProperty]] are too weak. The culprit is, as far as I can tell, that we re-used the state transitions allowed by DefineOwnProperty,

Re: Object.freezing proxies should freeze or throw?

Good catch. This appears to be a genuine spec bug. First, I thought that the problem simply was due to sloppy-mode silent failures, as a call to Object.isFrozen revealed that the proxy is not actually frozen after the call to Object.freeze. When your script is run in strict mode, it fails: on

Re: Exporting ES tests to a webpage environment?

Alex Vincent <ajvinc...@gmail.com>: > I'm wondering how I could test a custom implementation of a ECMAScript > standard API in a web browser, against existing test suites that might not > run in a browser. > > > > I've been re-exploring implementing a Membrane, which

Re: Proxy handler.has() does not have a receiver argument?

2016-03-19 0:15 GMT+01:00 Michael Theriot : > To be clear, I'm not suggesting behavior like `getOwnPropertyNames` be > overridden by anything on the prototype, just a way to use proxies without > having to instantiate identical copies that all use the same handler.

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-04 23:04 GMT+01:00 Matthew Robb <matthewwr...@gmail.com>: > > On Wed, Nov 4, 2015 at 4:46 PM, Tom Van Cutsem <tomvc...@gmail.com> wrote: > >> 1) If a module A hands out a reference to, say, a function f to modules B >> and C, then C could use this pr

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-03 15:41 GMT+01:00 Matthew Robb : > I probably have a terrible understanding of how this all works at a low > level but I feel like a potential solution would be a method of "upgrading" > a non-proxy object to be a proxy. The reason accessors are being used as >

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-04 0:22 GMT+01:00 Coroutines : > > With Object.observe() you get a global view of events generated by the > target object, with Proxy you need to replace references to the target > object with references to the Proxy. > > Now I'm changing my opinion again. We need

Re: Save Object.observe()! (please) + make WeakMap/WeakSet observable.

2015-11-02 23:34 GMT+01:00 Coroutines : > > I come from Lua. In Lua we make proxy objects with metamethods. You > create an empty table/object and define a metatable with a __index and > __newindex to catch accesses and changes when a key/property doesn't > exist. I would

Re: Calling toString on function proxy throws TypeError exception

2015-10-27 12:47 GMT-04:00 Jordan Harband : > > Shouldn't tests in existing code that rely on `Function#toString` not > throwing to indicate that something is callable, or throwing to indicate > that it is not, remain true for a function proxy? > Excluding some host objects (as

Re: Calling toString on function proxy throws TypeError exception

2015-10-22 23:09 GMT+02:00 Allen Wirfs-Brock : > > > Why would it be reasonable to do this for `toString`, but not also `call`, > `apply`, and `bind`? And ultimately this problem exists for all built-in > methods that have have internal state dependencies. I just don’t see

Re: Calling toString on function proxy throws TypeError exception

2015-10-22 21:03 GMT+02:00 Mark Miller : > Ok, that all makes sense and is fine with me. Thanks for clarifying. > > Tom, I'm still curious what you remember? > What I remember is that the original direct proxies spec did the transparent forwarding. wiki.ecmascript.org still

Re: await on synchronous functions

2015-07-27 5:42 GMT+02:00 Dean Landolt d...@deanlandolt.com: On Sun, Jul 26, 2015 at 8:07 AM, Benjamin Gruenbaum benjami...@gmail.com wrote: Out of curiosity, can you give an example of the Not Good parts? ISTM the await prefix is more of an explicit cast than an implicit conversation,

Re: await on synchronous functions

2015-07-17 19:41 GMT+02:00 Andrea Giammarchi andrea.giammar...@gmail.com: If I might, if there's one thing that has never particularly shone in JS, that is consistency. I see only two possibilities here: 1) it throws with non Promises 2) it Promisify anything that's not a Promise as if it

Re: ES6 Proxy Function Call Trap

Edwin, I sympathize with your point-of-view, but we've debated all the pros and cons of `invoke` long ago, and unless new arguments are brought to the table, I don't think it will be added again soon. To clarify why the invoke = get + call equivalence is so important, consider for instance the

Re: Maybe we need a reflect API to iterate over instance members

2015-06-01 20:36 GMT+02:00 Alexander Jones a...@weej.com: On Monday, June 1, 2015, Tom Van Cutsem tomvc...@gmail.com wrote: Or since Proxy traps correspond 1-to-1 to the internal methods in the spec, the primary goal of the Reflect API was to expose the essential methods that make up

Re: Maybe we need a reflect API to iterate over instance members

2015-06-01 8:38 GMT+02:00 Domenic Denicola d...@domenic.me: From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gray Zhang I’m just wondering is there any reason that Reflect API is not suitable to provide such functionality? Reflect currently contains only methods which

Re: Subclassing ES6 objects with ES5 syntax.

2015-04-28 5:01 GMT+02:00 Kevin Smith zenpars...@gmail.com: Looking over the Reflect namespace, I also see that Reflect.get and Reflect.set have been given powers not expressible with syntax: the receiver does not have to be a prototype parent of the target. Did you mean the receiver does

Re: super.prop assignment can silently overwrite non-writable properties

2015-04-21 22:15 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Yes, I considered that possibility in deciding upon the proposed change. The reason I error out if the Receiver property is an accessor is because I think the most likely way this scenario will occur is when that that access

Re: super.prop assignment can silently overwrite non-writable properties

2015-04-21 21:52 GMT+02:00 Kevin Smith zenpars...@gmail.com: Another interpretation might be that since you've explicitly stated an intention to bypass the receiver's setter, falling back to that setter would be a bug. No, that wouldn't be right. To clarify, Reflect.set takes the following

Re: super.prop assignment can silently overwrite non-writable properties

FWIW, you can reproduce this test case without reference to the new `super` syntax: ``` var parent = {}; var x = Object.create(parent, { prop: { value: 1, configurable: true, writable: false } }); Reflect.set(parent, prop, 2, x); // expected false, but under current semantics will return true

Re: Reflect.getOwnPropertySymbols?

2015-03-16 17:53 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com: It's possible, that in the future derived reflective operations such as those might be added to Reflect.*. There are a couple of design questions to consider for future extensions: 1) Is there any benefit to duplicating to

Re: @@toStringTag spoofing for null and undefined

2015-01-21 0:01 GMT+01:00 Mark S. Miller erig...@google.com: What I think I remember hearing from Tom is that Dave's main point, and the main argument with Tom, was precisely allowing proxies to intercede on === checks, in which case you wouldn't even have that as a reliable indicator. This

Re: @@toStringTag spoofing for null and undefined

Hi Dave, On Tue, Jan 20, 2015 at 4:44 PM, David Ungar un...@mac.com wrote: Self stratifies things into base- and meta- level. The idea is that almost all code is better off sticking to base level because that promotes encapsulation and reuse. At base-level all you can do is throw messages

Re: Add Reflect.isConstructor and Reflect.isCallable?

Adding Reflect.{isCallable, isConstructor} looks reasonable to me. If the spec needs these internally, chances are JS developers will need them at one point. And as you note, typeof === function is a common work-around in use today. So +1. 2014-12-21 0:20 GMT+01:00 Tom Schuster t...@schuster.me:

Re: [[DefineOwnProperty]] (P, Desc)

2014-11-27 12:05 GMT+01:00 Axel Rauschmayer a...@rauschma.de: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc Quote (note typo in second item): 1. A property cannot be added as or modified to be

Re: Is `List` really a specification type?

2014-11-27 17:12 GMT+01:00 Claude Pache claude.pa...@gmail.com: Lists are indeed specification-only types, and the result of the `[[OwnPropertyKeys]]` internal method call is never directly observed by the programmer: it is only used as an intermediate result within algorithms. A List is, I

Re: 9.5.8 [[Get]] (P, Receiver)

2014-11-27 12:32 GMT+01:00 Axel Rauschmayer a...@rauschma.de: Suggestion: mention in both cases that the property is an own property of the target. +1. It doesn't hurt to be too explicit in stating these invariants. It may help Allen if you can repost this as a bug in the ecmascript bug

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-17 18:30 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com: But probing through the proxy as has been proposed is a terrible violation of the MOP API boundary and isn't generalizable to other built-ins that are dependent upon internal state. While a null handler proxy on a direct

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-17 3:34 GMT+01:00 Frankie Bagnardi f.bagna...@gmail.com: Consider when Array.isArray would be used. In my experience, checks to see if something is an array are used for: - deciding how to iterate it (for(;;) vs for..in, for example) This is a good one. Here, again, a typical

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-14 21:00 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com: On Nov 14, 2014, at 11:41 AM, Domenic Denicola wrote: Yeah, more or less. A realm-independent instanceof. This makes sense also from the historical perspective that `Array.isArray` was meant to provide a cross-realm

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-13 22:35 GMT+01:00 Tom Van Cutsem tomvc...@gmail.com: My intuition is that Array.isArray is often used to branch based on whether code received just one versus a collection of values. E.g. a function may take a single parameter that can be bound to either a single value

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-14 21:52 GMT+01:00 Jeremy Martin jmar...@gmail.com: Allen's previous comments: Proxies are not transparent forwarders! In particular their default handling of the `this` value on method invokes will break any built-in method that needs to access internal slots of an object.

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-13 20:31 GMT+01:00 Allen Wirfs-Brock al...@wirfs-brock.com: 3) Proxies. Should Array.isArray treat proxy instances specially? To answer this question we need to think about what a ES programmer actually thinks Array.isArray means? The meaning that ES5 established is that

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

I agree with your sentiment. I have previously advocated that Array.isArray should be transparent for proxies. My harmony-reflect shim explicitly differs from the spec on this point because people using the shim spontaneously reported this as the expected behaviour and thought it was a bug that

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-12 19:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com: I agree and I want to know if you think this is worth revisiting once more? Next meeting's agenda? I don't think we've ever discussed this issue before during a TC39 meeting (but I didn't attend quite a few, so I may be wrong).

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-12 20:37 GMT+01:00 Kevin Smith zenpars...@gmail.com: In general, it appears that SM unwraps proxies so that internal slot access is transparently forwarded. I don't see any such unwrapping in the ES spec though. I assume that the spec is correct? This auto-unwrapping for internal

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-12 23:49 GMT+01:00 Andrea Giammarchi andrea.giammar...@gmail.com: If Array.isArray should fail for non pure Arrays, can we have a Proxy.isProxy that never fails with proxies ? We ruled out `Proxy.isProxy` very early on in the design. It's antithetical to the desire of keeping proxies

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-12 20:53 GMT+01:00 Rick Waldron waldron.r...@gmail.com: Done https://github.com/tc39/agendas/blob/master/2014/11.md Thanks. A related point: my harmony-reflect shim also patches Array.prototype.concat such that it recognizes proxies-for-arrays and will splice their elements (rather

Re: Array.isArray(new Proxy([], {})) should be false (Bug 1096753)

2014-11-13 8:18 GMT+01:00 Andreas Rossberg rossb...@google.com: On 12 November 2014 17:23, Tom Van Cutsem tomvc...@gmail.com wrote: My opinion is that array testing is fundamental to core JS and is worth the exception. This change would only make sense if we also were to special-case all

Re: Spec bug (proxies)? 9.5.8 [[Get]] (P, Receiver)

2014-11-02 22:10 GMT+01:00 Axel Rauschmayer a...@rauschma.de: OK. It surprised me, because `get` is so much about inheritance chains. I’ve not seen a rationale for the proxy invariants anywhere (including your technical report on proxies). Can I read up on it somewhere? Do you mean the

Re: Spec bug (proxies)? 9.5.8 [[Get]] (P, Receiver)

No, the proxy invariant checking mechanism never looks at inherited properties. Invariants related to frozenness (non-configurable, non-extensible) relate only to own properties. For example, even if an object is frozen, it may still inherit from a non-frozen object whose interface may change. And

Re: Proposal: Abstract References

2014-10-27 15:00 GMT+01:00 Andreas Rossberg rossb...@google.com: but without breaking membrane transparency. I'm still not sure I understand how this affects membranes specifically. A membrane would never pass a proxied object to a non-proxied function from the same side. So functions

Re: Making operations on property descriptors more robust against Object.prototype hazards

2014-09-13 17:49 GMT+02:00 Brendan Eich bren...@mozilla.org: It's not nice to lose .toString, though. Tom, didn't you have an idea for a fix? I can't find it but vaguely recall it (or dreamt it!). No, not that I know of. As highlighted in the old thread linked to by Claude, there is a

Re: Does async/await solve a real problem?

2014-09-11 16:22 GMT+02:00 Florian Bösch pya...@gmail.com: A - B - C - D - E changes to A - B - C - D - async E and causes A await - B await - C await - D await - async E And of course if A, B, C or D is used anywhere else it percolates trough the entire call graph. Trying to protect

Re: Violations of internal method invariants?

2014-07-31 15:43 GMT+02:00 Jason Orendorff jason.orendo...@gmail.com: Right Thing: I think [[PreventExtensions]] on these objects should always return false. I think [[DefineProperty]] on these objects should return false if Desc.[[Configurable]] is false or if it's missing and would default

Re: Violations of internal method invariants?

2014-07-31 15:26 GMT+02:00 Jason Orendorff jason.orendo...@gmail.com: There's not a rule that says flat-out, If Desc.[[Configurable]] is false and [[DefineOwnProperty]](P, Desc) returns true, that counts as 'observing' the property P as a non-configurable property on the target. but if you

Re: Violations of internal method invariants?

Hi Boris, It seems you're right (reproduced on Chrome and Safari). These examples clearly violate all the invariants related to non-configurable properties. If I understand correctly, the form DOM element's named input properties 'shadow' the actual JS properties defined on the DOM object. Even

Re: Reflect.hasOwn() ?

2014-07-27 18:14 GMT+02:00 Mark S. Miller erig...@google.com: Although there is some interesting work in trying to obtain security relevant guarantees from a script that isn't first, where a malicious script may instead have been first (link please if anyone has it), this work did not seem

Re: Reflect.hasOwn() ?

2014-07-26 5:43 GMT+02:00 Axel Rauschmayer a...@rauschma.de: ECMAScript 6 mostly eliminates the need to call methods generically (no need to use the array-like `arguments`, `Array.from()`, spread operator, etc.). The only exception that comes to my mind is `{}.hasOwnProperty.call(obj, key)`

TOCTTOU issue in Proxy invariant checks

Hi, While reviewing some changes to the Proxy spec in the latest revision, it occurred to me there is a potential time-of-check-to-time-of-use (TOCTTOU) issue in the Proxy invariant checks. Concretely, take revision 26, section 9.5.12 [[OwnPropertyKeys]]: - step 11 checks whether the target

Re: @@new

I really like this proposal. 2014-06-17 21:32 GMT+02:00 C. Scott Ananian ecmascr...@cscott.net: +1. I think you could also remove the 'construct' handler in Proxy ( http://people.mozilla.org/~jorendorff/es6-draft.html#sec-construct-internal-method step 4), as the @@new method can be

Re: IsConstructor

2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Anotherconcern I have with @@new, it that it exposes two extension points, @@new and @@create, on very constructor. I'm afraid that it wouldn't be very clear to most ES programmers when you should over-ride one or the other.

Re: IsConstructor

Interesting. It'd be nice if we could further simplify the Proxy/Reflect API. Given the local nature of these changes, we might still include it in ES6 if we achieve quick consensus. As Allen mentioned, this came up a number of times in TC39 meetings and I believe the fear for exotic objects that

Re: IsConstructor

2014-06-11 16:48 GMT+02:00 Erik Arvidsson erik.arvids...@gmail.com: [*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the IsConstructor will always return true which is really not what you want. If IsConstructor was changed to check for a .prototype instead proxies

Re: IsConstructor

2014-06-11 18:02 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Kind of boarder line. 6.1.7.2 says that the essential internal methods are those listed in Table 5 (does not include [[Call]] and [[Constructor]]). Also the definitions of [[Call]] and [[Construct]] in 9.5 each include a

Re: Object.getOwnPropertyDescriptor can return just about anything

unlikely). Cheers, Tom 2014-05-09 0:11 GMT+02:00 Rick Waldron waldron.r...@gmail.com: On Thu, May 8, 2014 at 5:23 PM, Tom Van Cutsem tomvc...@gmail.com wrote: Allen, Mark and I discussed the [[Origin]] issue and came to the following consensus: We remove [[Origin]] and revert

Re: Object.getOwnPropertyDescriptor can return just about anything

2014-05-09 9:57 GMT+02:00 David Bruant bruan...@gmail.com: Just to try to assess the unlikelihood and understand the cases where a ES5 code expectations aren't met: The only case where ES6 and ES5 may diverge is for Object.getOwnPropertyDescriptor where a Proxy may return something that

Re: Object.getOwnPropertyDescriptor can return just about anything

Allen, Mark and I discussed the [[Origin]] issue and came to the following consensus: We remove [[Origin]] and revert to the originally specified behavior ( http://wiki.ecmascript.org/doku.php?id=harmony:proxies_spec) where the descriptor returned by the proxy is coerced into a fresh, normalized,

Re: Proxy .__proto__ is not getPrototypeOf?

2014-05-05 19:40 GMT+02:00 John Barton johnjbar...@google.com: I'm hoping someone can explain this result which surprises me. If I create an object with a Proxy-ed prototype, the resulting object does not obey .__proto__ equal Object.getPrototypeOf(). There's no such equivalence, even for

Re: Object.getOwnPropertyDescriptor can return just about anything

2014-04-30 3:29 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com: Again, there is nothing new here. At the very least you should look at the old discussion about this. Pointers to the old discussions: I first commented on [[Origin]] as part of my review of the first ES6 draft Proxy spec:

Re: Object.getOwnPropertyDescriptor can return just about anything

2014-04-30 18:55 GMT+02:00 Mark Miller erig...@gmail.com: This is a stop-the-train scale disaster. ES6 cannot ship in this state. We need to fix this asap. I agree we need to revisit and iron out the details asap, but keep your calm. I'm sure we'll be able to fix this well in time before the

Re: Object.entries(), Object.values()

2014-03-22 3:14 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net: Sorry for the confusion. I was actually referring to [[OwnPropertyKeys]] returning an Array, as discussed previously: http://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34 Presumably the

Re: Enriched Descriptors, maybe ES7 ?

2014-03-09 21:05 GMT+01:00 Brendan Eich bren...@mozilla.com: Tom has experimented, IIRC. I don't know which implementations preserve extended property descriptor properties. As Allen mentioned earlier, proxies should receive in their defineProperty trap the full descriptor object as it was

Re: Enriched Descriptors, maybe ES7 ?

2014-03-10 11:10 GMT+01:00 David Bruant bruan...@gmail.com: Using Firefox's built-in direct proxies implementation I get a TypeError. I'll investigate further and file a bug. You already did https://bugzilla.mozilla.org/show_bug.cgi?id=601379 ;-) Thanks for refreshing my memory on that one

Re: Object.getOwnPropertyDescriptors(O) ? // plural

2014-03-07 0:51 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net: On Thu, Mar 6, 2014 at 6:31 PM, André Bargull andre.barg...@udo.edu wrote: On 3/6/2014 11:35 PM, Andrea Giammarchi wrote: The proposed [[GetOwnPropertyNames]] internal method is supposed to be a more restrictive version of

Re: Object.getOwnPropertyDescriptors(O) ? // plural

2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net: On Wed, Mar 5, 2014 at 1:39 PM, Tom Van Cutsem tomvc...@gmail.com wrote: Object.getOwnPropertyDescriptors(proxy) would trigger the getOwnPropertyNames trap, followed by calls to the getOwnPropertyDescriptor trap for each

Re: ES6 Tasks and TaskQueues

The benefit of turn is that I've seen this terminology used almost exclusively for denoting an atomic turn of an event loop (tick is also often used). By contrast, terms such as task are used much more broadly (e.g. tasks scheduled on a thread pool). Just my 2c. 2014-03-04 19:47 GMT+01:00 Mark

Re: New ES6 spec draft (Rev 22, Jan 20, 2014)

I really like the way the ES6 spec is coming together. Generally the way in which abstract ops are used and internal methods are specified is much clearer and more uniform in ES6 than in ES5. Also, the table of contents is much better structured. I like your classification according to indexed

Re: Reflect.* naming: defineProperty, deleteProperty vs. get, has, set?

'deleteProperty' was in fact originally called 'delete'. We changed it to avoid a conflict with the keyword, which occurs when importing the function (recall that the Reflect.* methods are actually functions exported from a module). While ES5 made it possible to use keywords as properties, you

Re: [[OwnPropertyKeys]]

2013/12/8 Brendan Eich bren...@mozilla.com We did not have consensus on per-object Get/SetIntegrity. I don't think we want the redundancy entailed. Implementors I've spoken with do not. This seems a dead snake, so no need to shoot at it. Thanks for digging up those links. Indeed, no need to

Re: [[OwnPropertyKeys]]

As currently specified, [[OwnPropertyKeys]] doesn't have any particular invariants on the values it generates from the returned iterator. Mark and I proposed to reintroduce [[GetOwnPropertyNames]] as a separate internal method, which would return an array rather than an iterator, but which would

Re: Reflecting on object properties

I share your concern (I already got confused when there were just Object.gOPN and Object.keys), but I'm skeptical that we can break the behavior of existing Object.* methods. You actually forgot Reflect.enumerate, which returns an iterator for all the own and inherited enumerable properties ;-)

Proxies and bind (Was: November 20, 2013 Meeting Notes)

I wasn't there on day 2 so I may be lacking context, but I'd like to clarify some parts in the notes re. proxies and Function.prototype.bind: 2013/11/27 Rick Waldron waldron.r...@gmail.com EA: What happens when do bind on a function proxy? MM: fail? DH: This is shocking. MM: bind is a

Re: November 19, 2013 Meeting Notes

2013/11/27 David Bruant bruan...@gmail.com Le 27/11/2013 19:14, Rick Waldron a écrit : BE: typeof depends if there is a call trap. instanceof depends on the prototype chain. All in the spec, so can create any object (apart from private state issues) Shouldn't it depend on the target's

Re: Weak callbacks?

2013/11/11 Mark S. Miller erig...@google.com Much of the early Actors research DEC SRC Network Objects RMI Original-E before I arrived at Electric Communities Midori Orleans AmbientTalk Cap'n Proto While I'm honored to see AmbientTalk listed among these systems, I should note that,

Re: Weak callbacks?

2013/11/13 Mark S. Miller erig...@google.com * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. Because Promises are asynchronous, even locally, the state of the world when a promise-based request is made differs from the one in which the request is

Re: [[Invoke]] and implicit method calls, once more

To confirm what Allen already mentioned: I too concluded from the discussion that we would remove [[Invoke]] from ES6. It is one of a few items I would like to put on the agenda of the TC39 November meeting to get a definitive consensus (the other item being the removal of the hasOwn() trap, for

Re: [[Invoke]] and implicit method calls, once more

2013/10/18 Till Schneidereit t...@tillschneidereit.net I share this concern. Last time we discussed it, Brendan said that we could implement it by falling back to .get if .invoke isn't defined[1]. I'm not sure how well that fits into the rest of the Proxy design, though. It doesn't fit the

Re: has the syntax for proxies been finalized ?

2013/10/18 Rick Waldron waldron.r...@gmail.com @Tom - since you know the status of the more recent Proxy wiki pages better than I do, would you mind adding the same h1 text to those that fit the description of obsolete? Thanks! Done! ___ es-discuss

Re: has the syntax for proxies been finalized ?

2013/10/18 Allen Wirfs-Brock al...@wirfs-brock.com This is what I currently have in my working draft of the ES6 spec: [...] In other words: you can say: Proxy(traget,handler) but not new Proxy(target, handler) It would be easy enough to allow new

Re: has the syntax for proxies been finalized ?

2013/10/21 Allen Wirfs-Brock al...@wirfs-brock.com see http://people.mozilla.org/~jorendorff/es6-draft.html#sec-standard-built-in-ecmascript-objects Paragraph 9: Built-in functions that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise

Re: has the syntax for proxies been finalized ?

Proxy.create and Proxy.createFunction are deprecated. The correct syntax is `new Proxy(target, handler)` In my original direct proxies proposal, the `new` was optional, so that `var p = Proxy(target, handler)` works equally well (cf.

Re: Multiple globals and changing prototypes

The relevant invariant for [[SetPrototypeOf]] is that if the target is non-extensible, and the operation returns true (i.e. appears to succeed), then [[GetPrototypeOf]] must return the same result as the value passed into [[SetPrototypeOf]]. This is what I got from the current ES6 draft:

Re: Proxying built-ins (Was: [[Invoke]] and implicit method calls)

2013/9/25 Boris Zbarsky bzbar...@mit.edu On 9/25/13 3:47 PM, Mark S. Miller wrote: Hi Boris, I don't understand what you mean by in general. I think the SpiderMonkey use of cross-realm membranes is a great use case for membranes, and I don't understand why they need any special logic at all

Re: Removing Proxy hasOwn() trap (Was: [[Invoke]] and implicit method calls)

I recall that Allen and I had previously agreed that it would be cleanest if each of the [[internal]] methods on Object would correspond 1-to-1 to a trap in the Proxy API (and I believe this is the case for the current ES6 draft). So my stance is that we should either remove both hasOwn() and

Re: [[Invoke]] and implicit method calls

2013/9/24 Brandon Benvie bben...@mozilla.com It seems unfortunate that we have to rely on a membrane for something as simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as currently specced gets us somewhere at least. You don't necessarily need a full membrane if you want that

Re: [[Invoke]] and implicit method calls

2013/9/24 Brendan Eich bren...@mozilla.com Brandon Benvie mailto:bben...@mozilla.com September 24, 2013 11:44 AM It seems unfortunate that we have to rely on a membrane for something as simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as currently specced gets us somewhere

Re: [[Invoke]] and implicit method calls

2013/9/25 Till Schneidereit t...@tillschneidereit.net Note that .invoke is not in that part, though: once proxies ship (in more than one browser) with all method calls invoking the .get handler, that ship has sailed. Suddenly not invoking the .get handler, anymore, will break applications.

Re: [[Invoke]] and implicit method calls

2013/9/23 Allen Wirfs-Brock al...@wirfs-brock.com On Sep 23, 2013, at 1:29 AM, Tom Van Cutsem wrote: I'm willing to consider changing the behavior of ForwardingHandler.get to auto-wrap functions and re-bind their this-value. I think you may be right that for users subclassing

Re: [[Invoke]] and implicit method calls

2013/9/24 Mark S. Miller erig...@google.com Ok, I've only been skimming the thread but I obviously missed something crucial. How would f.call(obj) cause obj's handler to be invoked at all, much less be given access to f? And why? This is exactly the hazard I alluded to in earlier mails.

Removing Proxy hasOwn() trap (Was: [[Invoke]] and implicit method calls)

[forking from [[invoke]]-thread for clarity] 2013/9/23 Jason Orendorff jason.orendo...@gmail.com On Mon, Sep 23, 2013 at 3:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote: To me hasOwn() is as much a primitive as e.g. Object.keys(). The only odd thing about it is that it lives

Re: [[Invoke]] and implicit method calls

2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com On Sep 21, 2013, at 2:51 AM, Tom Van Cutsem wrote: 2013/9/20 Allen Wirfs-Brock al...@wirfs-brock.com BTW, I would want to use [[InvokeFunction]] for both directly obj.method() and in the internals of F.p.call/apply As I mentioned

Re: [[Invoke]] and implicit method calls

2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com On Sep 21, 2013, at 2:53 AM, Tom Van Cutsem wrote: 2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote: Given this, having the legacy internal calls continue to use get+call seems fine

Re: [[Invoke]] and implicit method calls

2013/9/22 Jason Orendorff jason.orendo...@gmail.com On Fri, Sep 20, 2013 at 6:27 PM, Brandon Benvie bben...@mozilla.com wrote: Actually, taking the precedent of removing getPropertyDescriptor, it's has that would be removed. I think the logic of the current design is: primitives we keep;

Re: [[Invoke]] and implicit method calls

2013/9/20 Allen Wirfs-Brock al...@wirfs-brock.com BTW, I would want to use [[InvokeFunction]] for both directly obj.method() and in the internals of F.p.call/apply As I mentioned to your reply at the time, I believe the latter would break the expectations of existing code. Code that uses

Re: [[Invoke]] and implicit method calls

2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com On Sep 20, 2013, at 4:27 PM, Brandon Benvie wrote: On 9/20/2013 12:19 PM, Jason Orendorff wrote: I think .hasOwn() should be removed. Actually, taking the precedent of removing getPropertyDescriptor, it's has that would be removed. The

  1   2   3   4   5   6   >