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 al...@wirfs-brock.com
Tom recently
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
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
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é
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
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
2013/2/18 Andreas Rossberg rossb...@google.com
On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com
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,
On Feb 20, 2013, at 9:24 AM, Tom Van Cutsem wrote:
2013/2/18 Andreas Rossberg rossb...@google.com
On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's to simplify the MOP and that simplification is directly reflected as
a simplification to the Proxy hander
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
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com 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
Le 20/02/2013 21:08, Kevin Reid a écrit :
On Wed, Feb 20, 2013 at 11:52 AM, Nathan Wall nathan.w...@live.com
mailto:nathan.w...@live.com 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
On Wed, Feb 20, 2013 at 12:15 PM, David Bruant bruan...@gmail.com 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
(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
al...@wirfs-brock.comwrote:
[...]
Also, I'm concerned that we have been overloading the meaning of the
[[Extensible]]
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.
2013/2/20 Allen Wirfs-Brock al...@wirfs-brock.com
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
On 16 February 2013 20:36, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Feb 14, 2013, at 11:46 AM, Andreas Rossberg wrote:
On 14 February 2013 01:05, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Where do without, means replaced with set/getIntegrity traps and objects
have explicit
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...
Great
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] = v;
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(secret);
On Mon, Feb 18, 2013 at 2:27 PM, Nathan Wall nathan.w...@live.com 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;
On Feb 14, 2013, at 11:46 AM, Andreas Rossberg wrote:
On 14 February 2013 01:05, Allen Wirfs-Brock al...@wirfs-brock.com 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
On Feb 14, 2013, at 1:14 AM, Tom Van Cutsem wrote:
2013/2/14 Allen Wirfs-Brock al...@wirfs-brock.com
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
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;
3
this message in context:
http://old.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp35013883p35026595.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss
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 medikoo+mozilla@medikoo.com
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).
.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://mail.mozilla.org/listinfo/es
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
Nabble.com.
___
es-discuss mailing
prevent accidental modifications of *existing*
API's
but disallowing custom extensions is too restrictive and not 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
On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson erik.arvids...@gmail.comwrote:
... and security sensitive code could just ban/alter the reflection
methods.
On Feb 15, 2013 8:29 AM, Brandon Benvie bben...@mozilla.com wrote:
I definitely agree that something like preventAccidentalExtensions
On 15 February 2013 14:29, Brandon Benvie bben...@mozilla.com 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
2013/2/14 Allen Wirfs-Brock al...@wirfs-brock.com
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
On 13 February 2013 13:39, David Bruant bruan...@gmail.com 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
Le 14/02/2013 18:11, Andreas Rossberg a écrit :
On 13 February 2013 13:39, David Bruant bruan...@gmail.com 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
On 14 February 2013 19:16, David Bruant bruan...@gmail.com 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,
On 14 February 2013 01:05, Allen Wirfs-Brock al...@wirfs-brock.com 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
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.
Andreas Rossberg wrote:
On 14 February 2013 19:16, David Bruantbruan...@gmail.com 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
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
Hi David,
2013/2/13 David Bruant bruan...@gmail.com
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
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
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
I think
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
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
44 matches
Mail list logo
