Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Allen and I had a conversation that clarified things. Essentially, the plan is to only have [[PreventExtensions]]/[[IsExtensible]] internal MOP methods, and to only have the corresponding preventExtensions/isExtensible traps for proxies. Proxies won't have isSealed, isFrozen, seal and frozen trap

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)" which does exactly the derived computation for sealed and frozen objects. I think André is right though about the bug in 8.3.3 step 2.a. Cheers, Tom 2013/3/17 Allen Wirfs-Brock > Tom recently suggested that that we real

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Tom recently suggested that that we really don't need MOP-level or trap operations from freezing, sealing and testing those states. Also, there seems to be minimal support for having explicit freeze/sealed integrity states or for adding integrity integrity states. So I'm probably going to go m

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

The incompatibility you've noticed is just a spec bug in [[HasIntegrity]]. In step 2a of 8.3.3, the value of [[Extensible]] needs to be inverted. With that change applied, the code snippet will return `true`. - André Hi

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Hi, Allen's latest draft (Rev. 14) contains the change where [[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into [[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy API (i.e. no has/getIntegrity traps yet), the definition of Object.{freeze,seal,preventE

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Tom Van Cutsem wrote: That said, I don't think this is enough evidence either for or against the breaking change. I have a hard time believing we can break ES5. It has been shipping for years (plural, at least in one case) in major browsers that evergreen their user bases. /be _

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013/2/20 Allen Wirfs-Brock > Finally, I still think we should further consider the feasibly of a > breaking change where > Object.preventExtensions(obj); for ( let k of > Object.getOwnPropertyKeys(obj)) > Object.defineProperty(obj,k,{configurable:false}); > is no longer equivalent to >

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Allen Wirfs-Brock wrote: Actually, no. Reducing API complexity (in this case, the Proxy handler API) at the expense of a little bit of added spec. complexity seems like a very reasonable trade-off. Plus, we are talking about spec. complexity, not necessarily implementation complexity. Sure,

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

(I do not yet have an overall opinion about get/setIntegrity. Here, I'm just answering and clarifying, not advocating.) On Wed, Feb 20, 2013 at 10:57 AM, Allen Wirfs-Brock wrote: [...] > Also, I'm concerned that we have been overloading the meaning of the > [[Extensible]] state by hanging other

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

On Wed, Feb 20, 2013 at 12:15 PM, David Bruant wrote: > And in an ES6 world, you'll probably use an actual WeakMap anyway? Using an actual WeakMap does not change matters: the intent is that after Object.freeze(o), you can't add new trademarks to o. Since the trademark info is not stored on the

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Le 20/02/2013 21:08, Kevin Reid a écrit : On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall > wrote: `Object.isFrozen` and `Object.isSealed` don't really seem that helpful to me for the very reasons you've discussed: They don't represent any real object state

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall wrote: > `Object.isFrozen` and `Object.isSealed` don't really seem that helpful to > me for the very reasons you've discussed: They don't represent any real > object state, so they don't accurately tell me what can be done with an > object. If I coul

RE: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

Allen Wirfs-Brock wrote: > I think I previously asked if anybody is aware of situations where  > Object.isFrozen tests are done but Object.freeze is not used to set > objects to the frozen state. So far, no answers. Anybody? Speaking just from my own experience as a user of ES5, I have not found

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

On Feb 20, 2013, at 9:24 AM, Tom Van Cutsem wrote: > 2013/2/18 Andreas Rossberg > On 16 February 2013 20:36, Allen Wirfs-Brock wrote: > > > It's to simplify the MOP and that simplification is directly reflected as > a simplification to the Proxy hander interface. Instead of 6 traps > (prev

get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

2013/2/18 Andreas Rossberg > On 16 February 2013 20:36, Allen Wirfs-Brock > wrote: > > > It's to simplify the MOP and that simplification is directly reflected > as a simplification to the Proxy hander interface. Instead of 6 traps > (preventExtensions, isExtensible, freeze, isFrozen, seal, is

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On Mon, Feb 18, 2013 at 2:27 PM, Nathan Wall wrote: > Claus Reinke wrote: > > Careful there, you're not done!-) With nodejs, adding the following > > > > var table = makeTable(); > > table.add(1); > > table.add(2); > > table.add(3); > > > > var secret; > > Object.defineProperty(Array.prototype,42

RE: A case for removing the seal/freeze/isSealed/isFrozen traps

Claus Reinke wrote: > Careful there, you're not done!-) With nodejs, adding the following > > var table = makeTable(); > table.add(1); > table.add(2); > table.add(3); > > var secret; > Object.defineProperty(Array.prototype,42,{get:function(){ secret = this;}}); > > table.get(42); > console.log(secr

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

as a "high-integrity" function: var freeze = Object.freeze, push = Function.prototype.call.bind(Array.prototype.push); function makeTable() { var array = []; return freeze({ add: function(v) { push(array, v); }, store: function(i, v) { array[i >>> 0] =

RE: A case for removing the seal/freeze/isSealed/isFrozen traps

David Bruant wrote: > ... > "Security" is very loaded with emotions of people afraid to have their > password stolen and "cyber attacks". It's also loaded with the notion of > human safety and human integrity which, as human beings are sensitive to. > Maybe I should start using a different word...

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On 16 February 2013 20:36, Allen Wirfs-Brock wrote: > > On Feb 14, 2013, at 11:46 AM, Andreas Rossberg wrote: > >> On 14 February 2013 01:05, Allen Wirfs-Brock wrote: >>> Where "do without", means replaced with set/getIntegrity traps and objects >>> have explicit internal state whose value is on

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Le 16/02/2013 23:31, Allen Wirfs-Brock a écrit : Will this not just shift the current complexity someplace else? Well, it means that for 100% backwards compatibility, Object.isFrozen would have to be something like: 1. Let state = obj.[[GetIntegrity]](); 2 If state is "frozen" return true;

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On Feb 14, 2013, at 1:14 AM, Tom Van Cutsem wrote: > 2013/2/14 Allen Wirfs-Brock > > On Feb 13, 2013, at 12:53 PM, David Bruant wrote: > >> Interesting. > >> So what would happen when calling Object.isFrozen on a proxy? Would >> Object.isFrozen/isSealed/isExtensible reach out directly to the

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On Feb 14, 2013, at 11:46 AM, Andreas Rossberg wrote: > On 14 February 2013 01:05, Allen Wirfs-Brock wrote: >> Where "do without", means replaced with set/getIntegrity traps and objects >> have explicit internal state whose value is one of >> normal/non-extensible/sealed/frozen (and possibly)

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On 15 February 2013 14:29, Brandon Benvie wrote: > I definitely agree that something like "preventAccidentalExtensions" > (disallows new properties through [[Put]] but not [[DefineOwnProperty]]) has > more common uses cases than preventExtensions, and for the precise reasons > that David said.

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson wrote: > ... and security sensitive code could just ban/alter the reflection > methods. > On Feb 15, 2013 8:29 AM, "Brandon Benvie" wrote: > >> I definitely agree that something like "preventAccidentalExtensions" >> (disallows new properties through

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

gt; > I don't see much good in disallowing extensions to prototypes we expose. > > it's not JS way. We can prevent accidental modifications of *existing* > API's > > but disallowing custom extensions is too restrictive and not friendly in > my > > opini

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

friendly in my > opinion. > > > > > -- > View this message in context: > http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html > Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at >

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

: http://mozilla.6506.n7.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp272443p272674.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mai

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Le 15/02/2013 11:03, Mariusz Nowak a écrit : I've worked a lot with ECMAScript5 features in last two years, and I must say I never found a good use case for Object.freeze/seal/preventExtensions, it actually raised more issues than it actually helped (those few times when I decided to use it). Cur

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

I like this direction: it would distinguish the user-level operation _assignment_ from the meta-level operation _definition_. I’m not sure where `delete` fits in, but it’s much less common, so less of a potential problem. On Feb 15, 2013, at 11:03 , Mariusz Nowak wrote: > > I've worked a lot

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

our new DOM bindings I wanted to pass > along, in case anyone is interested: > > https://bugzilla.mozilla.org/show_bug.cgi?id=769911 > > Thanks to bz for the link. This is yet another inline cache > specialization for expandos on nodelists. > > /be > _

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Andreas Rossberg wrote: On 14 February 2013 19:16, David Bruant wrote: Le 14/02/2013 18:11, Andreas Rossberg a écrit : You're being vastly over-optimistic about the performance and the amount of optimisation that can realistically be expected for proxies. Proxies are inherently unstructured, h

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Andreas Rossberg wrote: But more importantly, I think you get too hung up on proxies as the proverbial hammer. Proxies are very much an expert feature. Using them for random micro abstractions is like shooting birds with a nuke. A language that makes that necessary would be a terrible language. A

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On 14 February 2013 01:05, Allen Wirfs-Brock wrote: > Where "do without", means replaced with set/getIntegrity traps and objects > have explicit internal state whose value is one of > normal/non-extensible/sealed/frozen (and possibly) "fixed-inheritance" > between normal and non-extensible to f

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On 14 February 2013 19:16, David Bruant wrote: > Le 14/02/2013 18:11, Andreas Rossberg a écrit : >> You're being vastly over-optimistic about the performance and the >> amount of optimisation that can realistically be expected for proxies. >> Proxies are inherently unstructured, higher-order, and

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Le 14/02/2013 18:11, Andreas Rossberg a écrit : On 13 February 2013 13:39, David Bruant wrote: Warning: In this post, I'll be diverging a bit from the main topic. Le 12/02/2013 14:29, Brendan Eich a écrit : Loss oread onlyf identity, extra allocations, and forwarding overhead remain problems

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On 13 February 2013 13:39, David Bruant wrote: > Warning: In this post, I'll be diverging a bit from the main topic. > > Le 12/02/2013 14:29, Brendan Eich a écrit : > >> Loss of identity, extra allocations, and forwarding overhead remain >> problems. > > I'm doubtful loss of identity matters often

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

2013/2/14 Allen Wirfs-Brock > > On Feb 13, 2013, at 12:53 PM, David Bruant wrote: > > Interesting. > > So what would happen when calling Object.isFrozen on a proxy? Would > Object.isFrozen/isSealed/isExtensible reach out directly to the target? or > a unique "state" trap returning a string for a

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

On Feb 13, 2013, at 12:53 PM, David Bruant wrote: > Le 13/02/2013 20:36, Tom Van Cutsem a écrit : >> Hi David, >> >> I went a bit too far suggesting frozen objects could de-facto disappear with >> proxies. >> I'm still unclear on the need for specific seal/freeze/isSealed/isFrozen >> traps >>

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Le 13/02/2013 20:36, Tom Van Cutsem a écrit : Hi David, I went a bit too far suggesting frozen objects could de-facto disappear with proxies. I'm still unclear on the need for specific seal/freeze/isSealed/isFrozen traps I think Allen and I reached consensus that we might do wi

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Hi David, 2013/2/13 David Bruant > Le 12/02/2013 14:29, Brendan Eich a écrit : > >> Loss of identity, extra allocations, and forwarding overhead remain >> problems. >> > I'm doubtful loss of identity matters often enough to be a valid argument > here. I'd be interested in being proved wrong, tho

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Warning: In this post, I'll be diverging a bit from the main topic. Le 12/02/2013 14:29, Brendan Eich a écrit : Loss of identity, extra allocations, and forwarding overhead remain problems. I'm doubtful loss of identity matters often enough to be a valid argument here. I'd be interested in bein

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

Loss of identity, extra allocations, and forwarding overhead remain problems. It seems to me that you are focusing too much on "share ... to untrusted parties." It's true you want either a membrane or an already-frozen object in such a setting. But the latter case, already-frozen object, does

A case for removing the seal/freeze/isSealed/isFrozen traps

Hi, The main use case (correct me if I'm wrong) for freezing/sealing an object is sharing an object to untrusted parties while preserving the object integrity. There is also the tamper-proofing of objects everyone has access to (Object.prototype in the browser) In a world with proxies, it's