Re: __proto__ security
Le 12/02/2012 23:47, Brendan Eich a écrit :
Oliver Hunt wrote:
On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote:
Heh, I knew that was coming. I'll amend to say of long standing
after implementations :-P.
I still have a gut feeling that someone is going to take advantage
of the setter for bad purposes that will be harder to block than
would be the case if __proto__ reflected as a data property. But I
can't prove this.
I'm not sure about this
Likewise, as noted -- I'm not sure but my gut is unhappy :-P
The case where you have to protect against someone who kept a reference
to the setter is when you haven't deleted the property at the beginning
(assuming you have a way to run first in the environment)
Within one vat, if you forgot, you're screwed, but you know it is easy
to fix (in your code, not necessarily the consequence on the attacked code).
An issue arise when other __proto__ setters pop up without you
necessarily knowing. And as far as I know, the only way it can happen is
when there are several frames within the same vat. So the cross-frame
check (or the stricter version based on Object.prototype) takes care of it.
But first thing, just delete Object.prototype.__proto__ anytime you
don't need it. Knowing this makes my guts feel far better than with the
current situation where, in Firefox, for instance, it is not possible to
get rid of Object.prototype.__proto__:
-
var o = {a:1}, o2 = {a:2};
var o3 = {b:3};
o3.__proto__ = o;
console.log(o3.a); // 1
delete Object.prototype.__proto__
o3.__proto__ = o2;
console.log(o3.a); // should be 1 if __proto__ was deletable, but is
currently 2 in Firefox Web Console
-
If you pull the setter function off of the prototype you can still
only apply it to objects you could already access.
The concern (no trolling here) is at least about attack surface. If
there's no setter that can be extracted, there's no need for the
frame check (however phrased). Adding that check adds more machinery
to get wrong or have interact in unexpected ways with other moving parts.
I'm not sure what you've described is directly a concern of attack
surface. I think it's rather a concern of potential bugs surface
(which can indirectly lead to security issues) and I agree that it's a
valid concern. However, the version where the check is based on the
Object.prototype identity sounds it could be written quite safely in a
couple of lines of JS, no ?
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
My suspicion: All these features make sense for the full-blown collections API, but for sets I’m not sure at which point they wouldn’t be “simple”, any more. Oliver Hunt makes a good case: “With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach.” An additional option is to introduce a “static” factory method: Set.fromIterable(). On Feb 13, 2012, at 4:29 , Michael A. Smith wrote: …But we wouldn't want to require the arguments to the set constructor to require instantiation itself/themselves, right? If a set has to be constructed with an Iterable, and cannot (also) be constructed with individual atoms, then you'll end up with use cases like Set(['foo', 'bar', 'baz']), which requires two constructions, one of which is essentially a waste. If allowing both forms of the constructor is distasteful, then why not just go with the multiple parameters, approach, and implement toSet() as a method on appropriate Iterables? -Michael A. Smith On Sun, Feb 12, 2012 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: The default argument should probably just be an iterable. On Feb 12, 2012 4:50 PM, Oliver Hunt oli...@apple.com wrote: I saw a reference to it being modified to take an array(-like?) as a parameter. While I can see an argument in favour of a single array argument I can also see using a set of parameters that initially populate the set. We just shouldn't allow both (and introduce another version of the horror that is the Array constructor). With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
Set.fromIterable() as factory is basically same as var s = Set.apply(null, ['alpha', 'beta']); since as it is for all native functions the constructor is a factory itself and no need to new my 2 cents, br On Mon, Feb 13, 2012 at 10:01 AM, Axel Rauschmayer a...@rauschma.de wrote: My suspicion: All these features make sense for the full-blown collections API, but for sets I’m not sure at which point they wouldn’t be “simple”, any more. Oliver Hunt makes a good case: “With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach.” An additional option is to introduce a “static” factory method: Set.fromIterable(). On Feb 13, 2012, at 4:29 , Michael A. Smith wrote: …But we wouldn't want to require the arguments to the set constructor to require instantiation itself/themselves, right? If a set has to be constructed with an Iterable, and cannot (also) be constructed with individual atoms, then you'll end up with use cases like Set(['foo', 'bar', 'baz']), which requires two constructions, one of which is essentially a waste. If allowing both forms of the constructor is distasteful, then why not just go with the multiple parameters, approach, and implement toSet() as a method on appropriate Iterables? -Michael A. Smith On Sun, Feb 12, 2012 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: The default argument should probably just be an iterable. On Feb 12, 2012 4:50 PM, Oliver Hunt oli...@apple.com wrote: I saw a reference to it being modified to take an array(-like?) as a parameter. While I can see an argument in favour of a single array argument I can also see using a set of parameters that initially populate the set. We just shouldn't allow both (and introduce another version of the horror that is the Array constructor). With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
True. Assuming that the spread operator works on any iterable, it is also the same as new Set(...iterable) On Feb 13, 2012, at 10:14 , Andrea Giammarchi wrote: Set.fromIterable() as factory is basically same as var s = Set.apply(null, ['alpha', 'beta']); since as it is for all native functions the constructor is a factory itself and no need to new my 2 cents, br On Mon, Feb 13, 2012 at 10:01 AM, Axel Rauschmayer a...@rauschma.de wrote: My suspicion: All these features make sense for the full-blown collections API, but for sets I’m not sure at which point they wouldn’t be “simple”, any more. Oliver Hunt makes a good case: “With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach.” An additional option is to introduce a “static” factory method: Set.fromIterable(). On Feb 13, 2012, at 4:29 , Michael A. Smith wrote: …But we wouldn't want to require the arguments to the set constructor to require instantiation itself/themselves, right? If a set has to be constructed with an Iterable, and cannot (also) be constructed with individual atoms, then you'll end up with use cases like Set(['foo', 'bar', 'baz']), which requires two constructions, one of which is essentially a waste. If allowing both forms of the constructor is distasteful, then why not just go with the multiple parameters, approach, and implement toSet() as a method on appropriate Iterables? -Michael A. Smith On Sun, Feb 12, 2012 at 9:29 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: The default argument should probably just be an iterable. On Feb 12, 2012 4:50 PM, Oliver Hunt oli...@apple.com wrote: I saw a reference to it being modified to take an array(-like?) as a parameter. While I can see an argument in favour of a single array argument I can also see using a set of parameters that initially populate the set. We just shouldn't allow both (and introduce another version of the horror that is the Array constructor). With the existence of the spread operator I think that there's a good argument in favour of the multiple parameters approach. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
As a starting point, would it make sense to provide an API that matches Array.prototype methods (where applicable)? On Mon, Feb 13, 2012 at 4:09 AM, Axel Rauschmayer a...@rauschma.de wrote: We do need a good suite of iterators including zip, etc. Let's have a proposal here, we can refine it quickly. True; a small note, Erlang has good standard library for lists including iterators: http://www.erlang.org/doc/man/lists.html, we can consider it and borrow some. Python has itertools: http://docs.python.org/py3k/library/itertools.html This falls into the general category of “rounding out the standard library”. I would love to have most of what Underscore has, too. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Set iterators
As a starting point, would it make sense to provide an API that matches Array.prototype methods (where applicable)? I think this ties in to my earlier desire to make Array.prototype methods work with iterators in general [1]. That is, I think the correct way to do this would be: 1) To specify that set is an iterator that, when iterated over, returns its values. 2) To specify that all iterators get (at least): every, filter, forEach, map, reduce, reduceRight, some One potential sticking point is that we might want filter and map to return sets themselves. [1]: https://mail.mozilla.org/pipermail/es-discuss/2012-February/020356.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Native Assertion module?
I was wondering if a native Assertion module had ever been discussed or proposed - I searched[1] and found nothing. If anyone can point me to existing discussion or proposals that I might have missed, I was be greatly appreciative. The simplest explanation of my thinking is something closer to a standard lib module, similar to Globalization or Iter. [1] http://wiki.ecmascript.org/doku.php?do=searchid=assert ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Mon, Feb 13, 2012 at 10:55 AM, Domenic Denicola dome...@domenicdenicola.com wrote: As a starting point, would it make sense to provide an API that matches Array.prototype methods (where applicable)? I think this ties in to my earlier desire to make Array.prototype methods work with iterators in general [1]. That is, I think the correct way to do this would be: 1) To specify that set is an iterator that, when iterated over, returns its values. 2) To specify that all iterators get (at least): every, filter, forEach, map, reduce, reduceRight, some +1 This is very intuitive and the sort of thing that real-world developers will be expecting One potential sticking point is that we might want filter and map to return sets themselves. Not sure if this is a sticking point or just a good idea. I'm leaning towards the latter :) [1]: https://mail.mozilla.org/pipermail/es-discuss/2012-February/020356.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On 12 February 2012 23:47, Brendan Eich bren...@mozilla.org wrote: The concern (no trolling here) is at least about attack surface. If there's no setter that can be extracted, there's no need for the frame check (however phrased). Adding that check adds more machinery to get wrong or have interact in unexpected ways with other moving parts. One could also make the proto accessor special in that reflecting it does only return a poisoned pair of getter/setters. Doesn't seem more magic or hacky than pretending that it is a data property. :) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
Let's try to get this back to concrete issues that I can incorporate into a
specification.
The current draft is at
http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Amagic_proto_propertycache=cachemedia=harmony:draft_proto_spec_rev2.pdf
Gavin and Oliver seem to really want to use an accessor for
Object.prototype.__proto__
Brendan has expressed a willingness to accepting under specify some the
Object.prototype.__proto__ property in ways that we normally wouldn't for
mandatory parts of the specification.
I could accommodate these two perspective by changing the first paragraph of
the draft B.3.1.1 to read:
The __proto__ property of the Object prototype property initially has the
attributes {[[Enumerable]]: false, [[Configurable]]: true}. The state of other
attributes and whether it is an accessor or data property is implementation
defined.
This would allow implementations to use either a data property or a access
property for Object.prototype.__proto__. However, the internal method
extensions are still needed in order to define the semantics in a manner that
allows either implementation approach to be used.
Finally, an alternative to extending [[Get]] and [[Put]] would be to extend the
GetValue abstraction operation (8.7.1) and the Simple Assignment evaluation
semantics (11.13.1).
[[DefineOwnProperty]] and [[Delete]] still need to be extended but, independent
of any of the above, these two can probably be made over-riding implementations
on Object.prototype rather than extending the default implementations used by
all objects.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 12, 2012, at 11:28 AM, Brendan Eich wrote: Heh, I knew that was coming. I'll amend to say of long standing after implementations :-P. :-D I still have a gut feeling that someone is going to take advantage of the setter for bad purposes that will be harder to block than would be the case if __proto__ reflected as a data property. But I can't prove this. Understood. We needed to change our implementation to fix ES5 compatibility issues with our prior mechanism. Implementing this internally as a accessor is much cleaner for us, and I think we'd want to keep it implemented this way even if we were to add the magic necessary to allow us to make it masquerade as a data descriptor (I still firmly side with Mark's strawman as to how this should be presented to users, but I didn't intend our current implementation to preclude alternatives). cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 13, 2012, at 9:55 AM, Allen Wirfs-Brock wrote: Finally, an alternative to extending [[Get]] and [[Put]] would be to extend the GetValue abstraction operation (8.7.1) and the Simple Assignment evaluation semantics (11.13.1). [[DefineOwnProperty]] and [[Delete]] still need to be extended but, independent of any of the above, these two can probably be made over-riding implementations on Object.prototype rather than extending the default implementations used by all objects. Hi Allen, I don't know if this is helpful, but Mark's strawman seemed to make this much simpler, perhaps it might make for a less intrusive specification to define that this should behave as if it is an accessor property following Mark's ProtoGetter/ProtoSetter descriptions, whilst leaving how the property is reflected ambiguous? I think this should amount to the same thing, just might be easier to encapsulate this way? cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Feb 13, 2012, at 11:43 AM, Gavin Barraclough wrote: On Feb 13, 2012, at 9:55 AM, Allen Wirfs-Brock wrote: Finally, an alternative to extending [[Get]] and [[Put]] would be to extend the GetValue abstraction operation (8.7.1) and the Simple Assignment evaluation semantics (11.13.1). [[DefineOwnProperty]] and [[Delete]] still need to be extended but, independent of any of the above, these two can probably be made over-riding implementations on Object.prototype rather than extending the default implementations used by all objects. Hi Allen, I don't know if this is helpful, but Mark's strawman seemed to make this much simpler, perhaps it might make for a less intrusive specification to define that this should behave as if it is an accessor property following Mark's ProtoGetter/ProtoSetter descriptions, whilst leaving how the property is reflected ambiguous? I think this should amount to the same thing, just might be easier to encapsulate this way? I believe what that amounts to is specifying the property as (not as if) an accessor property with ProtoGetter/ProtoSetter get/set functions and then specifying a [[GetOwnProperty]] over-ride for Object.prototype.__proto__ that allows an implementation to choose between returning a data property descriptor and returning a accessor property descriptor with censored get/set functions. There would still need to be a way to specify that special treatment of __proto__ in object literals is disabled when Object.prototype.__proto__ is modified or deleted. While this could be done with prose I think using [[Delete]] and [[DefineOwnProperty]] hooks (and the UnderscoreProtoEnabled variable) is a more precise why to specify what actions are required to actually disables __proto__. In general, I prefer preciseness over conciseness in the specification. Also, I think we need some more thought about how the approaches (specified as accessor vs. specified as [[Put]]/[[Get]] extensions) differ in the presence of proxies. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: __proto__ security
On Mon, Feb 13, 2012 at 9:55 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: [...] This would allow implementations to use either a data property or a access property for Object.prototype.__proto__. -1. I prefer any securable fully specified alternative discussed in this thread (including your prior draft) over leaving such broad observables unspecified. It reminds me of a story: I am old enough that I remember when programmers felt passionately about byte order. There were high endian machines and their advocates, and there were low endian machines and their advocates. (I was low endian myself back then.) Decades later, I forgot all about these strong feelings until I heard someone (Bill Frantz?) observe: Compared to the status quo, both sides now prefer that the other side had won. I certainly do. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Feb 13, 2012, at 2:21 PM, Domenic Denicola dome...@domenicdenicola.com wrote: If you do a native Assertion module, maybe it should be similar to node's. http://nodejs.org/docs/latest/api/assert.html It's worth noting that Node's assert is almost (?) identical to CommonJS's Unit Testing spec [1]. I'm not sure which came first. Regardless, I think this is the job for a body like CommonJS (as problematic as it may be), not Ecma. I speak for myself and my colleagues when I say that we've had our fill of including scripts _just_ for the sake of having a common testing interface. Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code. [1]: http://wiki.commonjs.org/wiki/Unit_Testing ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
[+tjclose] On Mon, Feb 13, 2012 at 5:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Yes. Insertion order. Is it iteration order? Well yes by definition ;). Did you mean to ask if it is insertion order? Yes. Is so this will add likely add space overhead to the internal representation of Set and Map and/or time overhead to insert/delete operations. Tyler Close previously posted a deterministic hash table implementation, with no extra space or time overhead. Before I saw it I thought it impossible. Also, for specializations of Set such as Integer Sets insertion order may not be the most desirable iteration ordering. That's a good point. Perhaps we can say that the abstract Map and Set contract merely demands that each concrete kind of Map or Set specify how their iteration order depends on their inputs. The default Maps and Sets can use insertion order (and typically be implemented using Tyler's algorithm.) -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Feb 13, 2012, at 6:03 PM, Mark S. Miller wrote: [+tjclose] On Mon, Feb 13, 2012 at 5:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Yes. Insertion order. Is it iteration order? Well yes by definition ;). Did you mean to ask if it is insertion order? Yes. yes Is so this will add likely add space overhead to the internal representation of Set and Map and/or time overhead to insert/delete operations. Tyler Close previously posted a deterministic hash table implementation, with no extra space or time overhead. Before I saw it I thought it impossible. Also, for specializations of Set such as Integer Sets insertion order may not be the most desirable iteration ordering. do you have the link to that post? That's a good point. Perhaps we can say that the abstract Map and Set contract merely demands that each concrete kind of Map or Set specify how their iteration order depends on their inputs. The default Maps and Sets can use insertion order (and typically be implemented using Tyler's algorithm.) I suspect that requiring a consistent or implementation independent iteration order for user written concrete Maps or Sets would be an unenforcable Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Mon, Feb 13, 2012 at 7:03 PM, Rick Waldron waldron.r...@gmail.comwrote: On Feb 13, 2012, at 2:21 PM, Domenic Denicola dome...@domenicdenicola.com wrote: If you do a native Assertion module, maybe it should be similar to node's. http://nodejs.org/docs/latest/api/assert.html It's worth noting that Node's assert is almost (?) identical to CommonJS's Unit Testing spec [1]. I'm not sure which came first. IIRC node's assert was built off the CommonJS spec and hasn't really diverged much since. Regardless, I think this is the job for a body like CommonJS (as problematic as it may be), not Ecma. CommonJS is effectively defunct. As far as I know TC-39 is really the only group in the position to pave this cowpath (and this is an explicit goal of harmony, after all). This is certainly a well-trodden path and it only needs the tiny subset of node's assert to be useful. The problem with API surfaced defined outside of TC-39 is there's no place to put them. Your `require(assert)` could be a lot different than mine, and this is a problem. A minimal API agreed to by the committee would go a long way helping here, especially if (like Set and Map) it was given a standard, official place in the global es environment. On a related note: has anyone given any thought to what shims should do about emulating @std modules? Or is there a programmatic loader API that's easy enough to shim in? That would make this kind of cowpath-paving far more fruitful. Another related note: isn't it about time the spec say something about console? :) I speak for myself and my colleagues when I say that we've had our fill of including scripts _just_ for the sake of having a common testing interface. Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code. Amen. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On 2/13/12 at 16:03, waldron.r...@gmail.com (Rick Waldron) wrote: Forget Date, typeof null, etc. JavaScript's biggest problem is devs that don't test their code. IMHO, things started going to the dogs in the mid-1970s when IBM decided to manage bugs instead of fixing them. It't been downhill ever since. :-) Cheers - Bill --- Bill Frantz|After all, if the conventional wisdom was working, the 408-356-8506 | rate of systems being compromised would be going down, www.periwinkle.com | wouldn't it? -- Marcus Ranum ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
I thought that Set wasn't going to even have insertion order as a possible. The idea behind any Set (outside of ES even) is that it is just a collection of elements, unordered. On Mon, Feb 13, 2012 at 19:32, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 12, 2012, at 4:52 PM, Peter Michaux wrote: In the proposal, iterators for Set are listed as todo. If engine implementers have decided to start moving forward implementing Sets, then it would be great if they could get iteration going sooner than later. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Is it iteration order? Is so this will add likely add space overhead to the internal representation of Set and Map and/or time overhead to insert/delete operations. Also, for specializations of Set such as Integer Sets insertion order may not be the most desirable iteration ordering. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Adam Shannon Developer University of Northern Iowa Sophomore -- Computer Science B.S. Mathematics http://ashannon.us ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
I expected a set would have an undefined iteration order to give implementations the opportunity to make optimizations that maintaining order would not allow. On Mon, Feb 13, 2012 at 8:06 PM, Adam Shannon a...@ashannon.us wrote: I thought that Set wasn't going to even have insertion order as a possible. The idea behind any Set (outside of ES even) is that it is just a collection of elements, unordered. On Mon, Feb 13, 2012 at 19:32, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 12, 2012, at 4:52 PM, Peter Michaux wrote: In the proposal, iterators for Set are listed as todo. If engine implementers have decided to start moving forward implementing Sets, then it would be great if they could get iteration going sooner than later. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Is it iteration order? Is so this will add likely add space overhead to the internal representation of Set and Map and/or time overhead to insert/delete operations. Also, for specializations of Set such as Integer Sets insertion order may not be the most desirable iteration ordering. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Adam Shannon Developer University of Northern Iowa Sophomore -- Computer Science B.S. Mathematics http://ashannon.us ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Feb 13, 2012, at 8:14 PM, Peter Michaux wrote: I expected a set would have an undefined iteration order to give implementations the opportunity to make optimizations that maintaining order would not allow. I would normally agree with you. ECMAScript for-in property enumeration order is defined in exactly that manner. However, the experience with JavaScript in browsers is that there is a significant amount of code that has been developed that depends upon a particular enumeration order that is widely used in browsers. People write code with dependencies (often unintentional) upon the enumeration order used by their favorite browser. If their code breaks when it is run on other browsers, they complain. Over time, this is a force that push browsers with less market share to match the implementation decisions of browser with more market share. This happened with for-in enumeration and I expect it will happen with Set/Map iteration order if we leave it unspecified. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
set.add and set.delete return values
The return value set.delete tells the caller if the set was modified or not. It would be useful if the return value of set.add did the same. For example, this way a model in MVC could efficiently know if and notify observers that a real change to the set actually happened. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Mon, Feb 13, 2012 at 21:25, Jason Orendorff jason.orendo...@gmail.com wrote: Unless TC39 specifies otherwise, the enumeration order of Map and Set will be arbitrary, it will certainly be inconsistent across browsers, and it will most likely even include a random component per Map/Set object. It is very hard to see how any code could depend on a particular implementation's enumeration order if it is randomized. I think we should be careful not to specify the iteration order and we should make sure that the first two implementations intentionally do not agree on the ordering. This is our one time chance to get this right and we don't want to paint us into another corner with Map/Set iteration order. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
[+tjclose] There are many benefits to determinism. E started with non-deterministic iteration order, which opens a covert channel hazard. I initially changed to deterministic order merely to plug this leak. Having done so, I found it had many software engineering benefits. For example, it becomes much easier to write regression tests and to reproduce bugs by re-execution. In my implementation, it also had a minor additional space and time cost. Tyler's Waterken tables show that even the minor runtime costs I was paying were unnecessary. Let's not introduce yet another source of non-determinism for the sake of an unmeasured efficiency. Let's measure, and if the cost turns out to be high after all, then let's reconsider determinism. Premature optimization is On Mon, Feb 13, 2012 at 10:22 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: On Mon, Feb 13, 2012 at 21:25, Jason Orendorff jason.orendo...@gmail.com wrote: Unless TC39 specifies otherwise, the enumeration order of Map and Set will be arbitrary, it will certainly be inconsistent across browsers, and it will most likely even include a random component per Map/Set object. It is very hard to see how any code could depend on a particular implementation's enumeration order if it is randomized. I think we should be careful not to specify the iteration order and we should make sure that the first two implementations intentionally do not agree on the ordering. This is our one time chance to get this right and we don't want to paint us into another corner with Map/Set iteration order. -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote: I speak for myself and my colleagues when I say that we've had our fill of including scripts _just_ for the sake of having a common testing interface. A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger the API, the harder it will be to standardize. I'm thinking maybe just a couple bare-bones primitives: 1. AssertionError : Error 2. assert(x === 12); // throws an AssertionError with a default error message 3. assert(x === 12, twelve, supposedly) // throws an AssertionError with the given error message Thoughts? Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Feb 13, 2012, at 6:43 PM, Dean Landolt wrote: On a related note: has anyone given any thought to what shims should do about emulating @std modules? Or is there a programmatic loader API that's easy enough to shim in? That would make this kind of cowpath-paving far more fruitful. There's definitely a programmatic loader API, but we're hacking on the wiki these days. More to come this week. Another related note: isn't it about time the spec say something about console? :) Could be, although we can't really mandate how console.log produces output. But we could at least say here's the API, and it can produce output in some host-environment-specific way. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.add and set.delete return values
there is a typo in the Set delete definition, return
private(this).delete(key) should be return private(this).map.delete(key);
AFAIK add does behave indeed like that and it's in my shim indeed, add
returns true if added, false otherwise.
I would change that code into
add(key) { const map = private(this).map; return !(map.has(key)
map.set(key, true)); }
br
On Tue, Feb 14, 2012 at 6:28 AM, Peter Michaux petermich...@gmail.comwrote:
The return value set.delete tells the caller if the set was modified
or not. It would be useful if the return value of set.add did the
same. For example, this way a model in MVC could efficiently know if
and notify observers that a real change to the set actually happened.
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
