Re: set.add and set.delete return values
typo in my line too
add(key) { const map = private(this).map; return !map.has(key)
!map.set(key, true); }
...
On Tue, Feb 14, 2012 at 8:58 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
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
Re: Set iterators
Map and Set do not use an index to be accessed then the iterator send the index of the key/value as last argument ... I would say either this index is not sent at all or, since present, should be specified somehow in the spec. talking about this Map#iterate(callback:Function, context:void*):void == callback.call(context, key, value, index) br ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? Also I would probably never use typed arrays to Set procedure ... that sounds against performances About new syntax, generators are new too so ... var s = Set(...(x * x for x of primes)); as well as all others ... still, I start thinking Set constructor is good as it is my 2 cents ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Le 14/02/2012 07:22, Erik Arvidsson a écrit : 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. It cannot be a one time chance. This property (implementations not agreeing) would need to be followed, because if at some point, some implementations do agree, we'll be back to where we started and people will start relying on enumeration order. Moreover, maybe the 2 first implementations will disagree, but maybe some implementations will agree (either in all cases or in some observable cases that people will use in their code). For instance, what if Firefox and Chrome disagree, but iPhone safari and Android Webkit agree? Also, some products (Node.js (V8), MongoDB (SpiderMonkey), etc.) rely only on one JS engine, so JS code written for these could rely on the particular order of the given implementation. If it is the case, it will force these implementations to keep their order for backward-compat sake. Worst case, 2 non-compatible implementations are forced to keep their different order for some products built on top of them each relying on the particular order, making it impossible later to specify a given order. Determinism makes JavaScript code more interoperable. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On 14 February 2012 09:47, David Bruant bruan...@gmail.com wrote: For instance, what if Firefox and Chrome disagree, but iPhone safari and Android Webkit agree? Also, some products (Node.js (V8), MongoDB (SpiderMonkey), etc.) rely only on one JS engine, so JS code written for these could rely on the particular order of the given implementation. If it is the case, it will force these implementations to keep their order for backward-compat sake. Worst case, 2 non-compatible implementations are forced to keep their different order for some products built on top of them each relying on the particular order, making it impossible later to specify a given order. To be sure, this is assuming that iteration order is fixed for a given implementation. If order is not specified, then I don't see why that should be required either. I.e., a completely randomized order (per iteration) should be valid, too. And I see potential reasons why order might differ for separate iterations over the same collection. Determinism makes JavaScript code more interoperable. I tend to agree. Underspecification in language definitions is a great source for sleeper bugs. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Le 14/02/2012 11:23, Andreas Rossberg a écrit : On 14 February 2012 09:47, David Bruantbruan...@gmail.com wrote: For instance, what if Firefox and Chrome disagree, but iPhone safari and Android Webkit agree? Also, some products (Node.js (V8), MongoDB (SpiderMonkey), etc.) rely only on one JS engine, so JS code written for these could rely on the particular order of the given implementation. If it is the case, it will force these implementations to keep their order for backward-compat sake. Worst case, 2 non-compatible implementations are forced to keep their different order for some products built on top of them each relying on the particular order, making it impossible later to specify a given order. To be sure, this is assuming that iteration order is fixed for a given implementation. If order is not specified, then I don't see why that should be required either. It is not required, but it's what experience tells us from the for-in loop. Spec said it was impl-specific, but implementations mostly implemented iteration order as insertion order. Regardless of requirement, if an implementation gets to a point where in cases observed by people looks deterministic, then they may assume it is, start relying on it and force the implementation to keep this order. Requiring fixed iteration order and same order for all implementations saves us from these issues. I.e., a completely randomized order (per iteration) should be valid, too. And I see potential reasons why order might differ for separate iterations over the same collection. I'm interested in hearing more :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On 14 February 2012 12:02, David Bruant bruan...@gmail.com wrote: Le 14/02/2012 11:23, Andreas Rossberg a écrit : To be sure, this is assuming that iteration order is fixed for a given implementation. If order is not specified, then I don't see why that should be required either. It is not required, but it's what experience tells us from the for-in loop. Doesn't experience rather tell us that people expect a specific enumeration order, not just some fixed one? And I see potential reasons why order might differ for separate iterations over the same collection. I'm interested in hearing more :-) Dynamic changes of representation, for example. V8 does things like that all the time. And it currently goes to some length to make for-in deterministic. (But just to be clear, I'm still in favour of fully specified behaviour.) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
There's both room and need for a built-in assert() IMHO -- I would like one which magically compiles to nothing in production code. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Feb 14, 2012, at 3:45 AM, Andreas Rossberg wrote: On 14 February 2012 12:02, David Bruant bruan...@gmail.com wrote: Le 14/02/2012 11:23, Andreas Rossberg a écrit : And I see potential reasons why order might differ for separate iterations over the same collection. I'm interested in hearing more :-) Dynamic changes of representation, for example. V8 does things like that all the time. And it currently goes to some length to make for-in deterministic. Good hash table designs typically rehash (reorganize) themselves when they reach a certain percentage of their total capacity or are experiencing too many hash collisions. One of the simplest iteration strategies for a hash table is often physical placement order. Rehashing will typically change the physical placement of entries and hence that ordering. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
I just happened to see http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0157.html which shows that other web standards efforts continue to struggle to identify and quash other sources of non-determinism in web standards. If unspecified iteration order is so good, wouldn't the same reasoning apply to bugs like that? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On 14 February 2012 18:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 14, 2012, at 3:45 AM, Andreas Rossberg wrote: Dynamic changes of representation, for example. V8 does things like that all the time. And it currently goes to some length to make for-in deterministic. Good hash table designs typically rehash (reorganize) themselves when they reach a certain percentage of their total capacity or are experiencing too many hash collisions. One of the simplest iteration strategies for a hash table is often physical placement order. Rehashing will typically change the physical placement of entries and hence that ordering. Indeed. But I had in mind more radical changes like going from e.g. a dense vector representation to a hashtable or a binary search tree. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Feb 14, 2012, at 9:35 AM, Andreas Rossberg wrote: On 14 February 2012 18:15, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 14, 2012, at 3:45 AM, Andreas Rossberg wrote: Dynamic changes of representation, for example. V8 does things like that all the time. And it currently goes to some length to make for-in deterministic. Good hash table designs typically rehash (reorganize) themselves when they reach a certain percentage of their total capacity or are experiencing too many hash collisions. One of the simplest iteration strategies for a hash table is often physical placement order. Rehashing will typically change the physical placement of entries and hence that ordering. Indeed. But I had in mind more radical changes like going from e.g. a dense vector representation to a hashtable or a binary search tree. Yes, all quite reasonable internal transformations for any identify-keyed data structure. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Tue, Feb 14, 2012 at 5:02 AM, David Bruant bruan...@gmail.com wrote: To be sure, this is assuming that iteration order is fixed for a given implementation. If order is not specified, then I don't see why that should be required either. It is not required, but it's what experience tells us from the for-in loop. All right, but let's not make the mistake of only learning from our own experience. Many other language communities have very specific relevant experience. For example, there is a single dominant Java implementation and a single dominant Python implementation. Have the other implementations been forced to duplicate the dominant implementation's hash table iteration order, because existing code depends on it? Have the dominant implementations been forced to back out memory management changes or hash table optimizations that would affect iteration order? I don't think that has ever happened. Python hash codes differ from version to version and from OS to OS. Jython has a completely different hashing function from CPython, even for strings. Keep in mind that hash tables are one of two core data structures in Python, so if code could sanely depend on iteration order, it would. Of course code will depend on unspecified behavior when that unspecified behavior is actually intelligible and useful. Experience suggests hash table iteration order is neither. Mark Miller is holding up the argument for determinism really well. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
unsubscribe
- ~Chris cmar...@apple.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Tue, Feb 14, 2012 at 1:51 AM, David Herman dher...@mozilla.com wrote: 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 Bingo :) Thoughts? Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale behind supporting Invalid Date
On Feb 12, 2012, at 3:02 PM, Brendan Eich wrote: Andrew Paprocki wrote: On Sat, Feb 11, 2012 at 8:32 PM, Brendan Eichbren...@mozilla.com wrote: It's well-specified by 15.9.3.1 etc. I was reading http://es5.github.com/x15.9.html and I see the spec for allowing NaN as the this time value. Where did the Invalid Date toString() came from? toString is underspeicified but it seems implementations all agree -- when the Date instance's time value is NaN, Invalid Date. I don't see it on that page at all, yet all the browsers seem to return it. We could spec this, FWIW. Not a big deal. now https://bugs.ecmascript.org/show_bug.cgi?id=268 I was thinking of trying it out when running in a debug mode to help catch errors. Is there any actual real use in the wild for a Date with a NaN value? Not sure. Probably, since it goes back 16 years. No one is inclined to find out the hard way, I bet. We could add throwing as a strict mode behavior but then we are enlarging strict mode from what it is today in shipping browsers. I would expect that this, isNaN(new Date(Date.parse(someString))) or an equivalent formulation occurs someplace on the web as a check for validity of date strings. The constructor call is not really necessary in this case but that doesn't mean that someone hasn't written code exactly like this. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Native Assertion module?
On Tue, Feb 14, 2012 at 10:45 AM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Feb 14, 2012 at 1:51 AM, David Herman dher...@mozilla.com wrote: 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 Bingo :) Is this significantly better than console.assert()? jjb Thoughts? Dave ___ 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: Native Assertion module?
On Tue, Feb 14, 2012 at 1:50 PM, John J Barton johnjbar...@johnjbarton.comwrote: On Tue, Feb 14, 2012 at 10:45 AM, Rick Waldron waldron.r...@gmail.com wrote: On Tue, Feb 14, 2012 at 1:51 AM, David Herman dher...@mozilla.com wrote: 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 Bingo :) +1 I assume nothing stops us from subtyping AssertionError either, right? Is this significantly better than console.assert()? Dave's assert throws an AssertionError (a new global, presumably?). But more importantly, it *actually throws*, which is an important departure from console.assert. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Freezing private state (was: Rationale behind supporting Invalid Date)
On Feb 12, 2012, at 1:36 PM, Mark S. Miller wrote: If the Date.prototype continues to be a valid Date object, which would be unfortunate, it should at least be a valid Date object representing an invalid unsettable date. I believe this is already what IE10 does. The invalidity isn't really necessary. What is necessary is that the internal Date representation of this special object be unsettable, since it cannot be made unsettable simply by freezing this object. Better would be to reform our pattern that a built-in Foo.prototype is a valid Foo object, with all the internal properties associated with a Foo, even though !(new Foo() instanceof Foo). Fortunately, of the existing built-in primordials, it is only for Date that this creates an unpluggable global communications channel. My current intent is to respecify the Date time value slot as a private named property rather than as an internal property. This will enable freezing of that property as well as enabling subclassing of Date. However, there is an issue. My current understanding is that we have agreed that Object.freeze and Object.seal will not reconfigure private named properties. Given our current stable of APIs, reconfiguring a private named property requires use of Object.defineProperty by someone who knows the private name. Do you think that Date will need an additional method that makes the time value immutable? Do we need to establish a convention for objects that want to enable public facing immutability requests? Note that immutability may not necessarily be the same thing as frozen or sealed. I can imagine situations (Date.prototype is a good example) where you would want to make an object immutable but still allow additions/modifications of methods or other new properties. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Le 14/02/2012 07:31, Mark S. Miller a écrit : [+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. Do you have a link to this implementation? If it's not obvious from the source code, can you give some insight on why Tyler's Waterken tables show that the minor costs were unnecessary? Thanks, David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Le 14/02/2012 19:28, Jason Orendorff a écrit : On Tue, Feb 14, 2012 at 5:02 AM, David Bruant bruan...@gmail.com wrote: To be sure, this is assuming that iteration order is fixed for a given implementation. If order is not specified, then I don't see why that should be required either. It is not required, but it's what experience tells us from the for-in loop. All right, but let's not make the mistake of only learning from our own experience. Many other language communities have very specific relevant experience. For example, there is a single dominant Java implementation and a single dominant Python implementation. Have the other implementations been forced to duplicate the dominant implementation's hash table iteration order, because existing code depends on it? Have the dominant implementations been forced to back out memory management changes or hash table optimizations that would affect iteration order? I don't think that has ever happened. Python hash codes differ from version to version and from OS to OS. Jython has a completely different hashing function from CPython, even for strings. Keep in mind that hash tables are one of two core data structures in Python, so if code could sanely depend on iteration order, it would. Of course code will depend on unspecified behavior when that unspecified behavior is actually intelligible and useful. Experience suggests hash table iteration order is neither. Interesting. I have to admit that I'm almost entirely ignorant of Python, but I have some basic knowledge of Java or at least know some heavy Java users, so I'll ask them if they know something on that topic and specifically if there was an impact on how they wrote code and transitionned from version to version. It seems to me that web browser JavaScript has a particularity in deployment that no other language has. When a JS engine feature is deployed, people use it. Then, the engine may want to do some changes. If it does, the new engine must be able to run code using the changed engine as well as old code. If it fails on the later, it's what we call breaking the web. It seems to me that no other programming language has such a constraint. Maybe some things were made not backward compatible in Java 7, but people have the choice to say all right, I'll stay on Java 6 until I'm ready to move to Java 7. They have the time to study the changes, add new unit tests in their own code if they think things can break between 6 and 7. They can gradually change their code in some cases. This is not a choice web authors have. The consequence we've seen so far was web authors relying on underspecified behaviors and the need to later specify a de facto behavior. I understand the point about hashcodes, but what garantees that all implementations will choose hashcode based iteration forever? Maybe, one day, V8 will decide that it's better to iterate keys in reverse insertion order, because they'll have found some awesome algo/data structure. Maybe Node.js users will start relying on this order, forcing V8 to be stuck. Then, maybe some best viewed on Chrome websites (we all know they exist) will rely on this iteration order (because they won't care testing on other browsers), forcing de facto standardization (to prevent breaking the web) Maybe it won't happen, maybe it will. Is the risk worth taking? If, in the end, there is a de facto standardization of iteration order, maybe one engine will have the good performance benefit that is praised here, but we'll see what the performance in engines for which this order wasn't the first choice. Once again, is the risk worth taking? Mark Miller is holding up the argument for determinism really well. And of course, determinism from the beginning would prevent this risk. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. Indeed. I'm looking forward to have an eye on Tyler Close Waterken tables. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.comwrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Tue, Feb 14, 2012 at 3:07 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? `Set(1, 2, 1)` then? Are you suggesting this should throw? So you'd need to dedupe your arguments before you construct a set with them? Isn't that a primary use case of sets? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.comwrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. 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
Re: Set constructor arguments
nope, Set does not even accept arguments as it is now ... does it ? On Tue, Feb 14, 2012 at 9:20 PM, Dean Landolt d...@deanlandolt.com wrote: On Tue, Feb 14, 2012 at 3:07 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? `Set(1, 2, 1)` then? Are you suggesting this should throw? So you'd need to dedupe your arguments before you construct a set with them? Isn't that a primary use case of sets? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.comwrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. 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
Re: Set length property
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: See the thread containing Dean Landolt's dissent on 'length' being the best name: https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. In today's practice, iterables are ducktyped by the presence of a length property. I don't think an [implication of] metric topology matters to basically anyone who's not a huge language-design nerd. ^_^ Additionally, having multiple names for the size of property makes it more difficult to learn, and more difficult to create generic code. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: See the thread containing Dean Landolt's dissent on 'length' being the best name: https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. In today's practice, iterables are ducktyped by the presence of a length property. IME they're ducktyped by the presence of forEach (this is far from perfect). Length has nothing to do with iterability. What about generators? I don't think an [implication of] metric topology matters to basically anyone who's not a huge language-design nerd. ^_^ I'm pretty sure math geeks would disagree. Additionally, having multiple names for the size of property makes it more difficult to learn, and more difficult to create generic code. That's a bold assertion. I'd argue that having two different names for two things that are *fundamentally different* is quite practical. It's especially useful for writing generic code ;) But more practically we *need *different names -- setting length has certain expectations that wouldn't hold across all collections. Violating these expectations would make things ever more difficult to learn...and generic code even harder to write. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Redefine spread to use iteration? (Was: Set constructor arguments)
On Feb 13, 2012, at 1:20 AM, Axel Rauschmayer wrote: True. Assuming that the spread operator works on any iterable, Not as currently specified. It does the same 0 to length generic property enumeration as is used within the Array extra functions. Changing to using an iterator probably would be possible, but we need to consider all the implications. For example, I would expect [...firstPart, ...secondPart] to be somewhat more expense if spread uses iterators rather than as currently defined. Is this extra cost justifiable in light of the most common use cases? Maybe, but I'm not totally sure? I think implementors know how to easily optimize the array accesses used in the current definition of spread. On first consideration, optimizing an iterator based loop seems fundamentally harder. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com wrote: On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: See the thread containing Dean Landolt's dissent on 'length' being the best name: https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. In today's practice, iterables are ducktyped by the presence of a length property. IME they're ducktyped by the presence of forEach (this is far from perfect). Length has nothing to do with iterability. What about generators? I don't want to go looking anything up right now, but I have lots of memories of things looking for the presence of length to denote an array-like. I don't think an [implication of] metric topology matters to basically anyone who's not a huge language-design nerd. ^_^ I'm pretty sure math geeks would disagree. We math geeks are also thin on the ground, so the point of my assertion (that the number of people who care is vanishingly small) still holds. Additionally, having multiple names for the size of property makes it more difficult to learn, and more difficult to create generic code. That's a bold assertion. I'd argue that having two different names for two things that are fundamentally different is quite practical. It's especially useful for writing generic code ;) They're not fundamentally different unless you go to some lengths (pun not intended) to make them so. length is the size of a collection; it doesn't immediately denote anything about the indexability of said collection. But more practically we need different names -- setting length has certain expectations that wouldn't hold across all collections. Violating these expectations would make things ever more difficult to learn...and generic code even harder to write. This sounds pretty reasonable. The fact that 'length' is settable on Array is pretty weird in the first place imo, and as you say, it's nonsensical for Set/Map. Okay, I'm more in favor of 'count' or something being a readonly on all the collections then, as you suggested in the thread Brendan linked, so that it can become the new length. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com wrote: On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: See the thread containing Dean Landolt's dissent on 'length' being the best name: https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. In today's practice, iterables are ducktyped by the presence of a length property. IME they're ducktyped by the presence of forEach (this is far from perfect). Length has nothing to do with iterability. What about generators? I don't want to go looking anything up right now, but I have lots of memories of things looking for the presence of length to denote an array-like. I don't think an [implication of] metric topology matters to basically anyone who's not a huge language-design nerd. ^_^ I'm pretty sure math geeks would disagree. We math geeks are also thin on the ground, so the point of my assertion (that the number of people who care is vanishingly small) still holds. No doubt. The long tail of geekery is long :) Additionally, having multiple names for the size of property makes it more difficult to learn, and more difficult to create generic code. That's a bold assertion. I'd argue that having two different names for two things that are fundamentally different is quite practical. It's especially useful for writing generic code ;) They're not fundamentally different unless you go to some lengths (pun not intended) to make them so. length is the size of a collection; it doesn't immediately denote anything about the indexability of said collection. What about sparse arrays? What's the difference between the count of items and the last index? These are two concepts, right? And as far as es is concerned `length` already denotes the last numerical index. But more practically we need different names -- setting length has certain expectations that wouldn't hold across all collections. Violating these expectations would make things ever more difficult to learn...and generic code even harder to write. This sounds pretty reasonable. The fact that 'length' is settable on Array is pretty weird in the first place imo, and as you say, it's nonsensical for Set/Map. Okay, I'm more in favor of 'count' or something being a readonly on all the collections then, as you suggested in the thread Brendan linked, so that it can become the new length. Great. The more I look around the more appropriate `count` seems. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Feb 14, 2012, at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote:
See the thread containing Dean Landolt's dissent on 'length' being the
best
name:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html
The January 19 2012 meeting notes recorded here:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
include At next meeting MarkM will present a tiny API proposal for maps
and
sets.
In today's practice, iterables are ducktyped by the presence of a
length property.
IME they're ducktyped by the presence of forEach (this is far from perfect).
Length has nothing to do with iterability. What about generators?
I don't want to go looking anything up right now, but I have lots of
memories of things looking for the presence of length to denote an
array-like.
Not only that, `length` is how ES's own Array methods control iteration.
[].forEach.call({ 0: bar, 1: qux }, function(val) { console.log(val); });
undefined
[].forEach.call({ 0: bar, 1: qux, length: 2 }, function(val) {
console.log(val); });
bar
qux
undefined
I don't think an [implication of] metric
topology matters to basically anyone who's not a huge language-design
nerd. ^_^
I'm pretty sure math geeks would disagree.
We math geeks are also thin on the ground, so the point of my
assertion (that the number of people who care is vanishingly small)
still holds.
Additionally, having multiple names for the size of property makes
it more difficult to learn, and more difficult to create generic code.
That's a bold assertion. I'd argue that having two different names for two
things that are fundamentally different is quite practical. It's especially
useful for writing generic code ;)
They're not fundamentally different unless you go to some lengths (pun
not intended) to make them so. length is the size of a collection;
it doesn't immediately denote anything about the indexability of said
collection.
But more practically we need different names -- setting length has certain
expectations that wouldn't hold across all collections. Violating these
expectations would make things ever more difficult to learn...and generic
code even harder to write.
This sounds pretty reasonable. The fact that 'length' is settable on
Array is pretty weird in the first place imo,
If you think of `length` in terms of measuring a physical thing, it's
not weird at all.
and as you say, it's
nonsensical for Set/Map. Okay, I'm more in favor of 'count' or
something being a readonly on all the collections then, as you
suggested in the thread Brendan linked, so that it can become the new
length.
~TJ
___
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: Freezing private state (was: Rationale behind supporting Invalid Date)
On Tue, Feb 14, 2012 at 11:08 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Feb 12, 2012, at 1:36 PM, Mark S. Miller wrote: If the Date.prototype continues to be a valid Date object, which would be unfortunate, it should at least be a valid Date object representing an invalid unsettable date. I believe this is already what IE10 does. The invalidity isn't really necessary. What is necessary is that the internal Date representation of this special object be unsettable, since it cannot be made unsettable simply by freezing this object. Better would be to reform our pattern that a built-in Foo.prototype is a valid Foo object, with all the internal properties associated with a Foo, even though !(new Foo() instanceof Foo). Fortunately, of the existing built-in primordials, it is only for Date that this creates an unpluggable global communications channel. My current intent is to respecify the Date time value slot as a private named property rather than as an internal property. This will enable freezing of that property as well as enabling subclassing of Date. However, there is an issue. My current understanding is that we have agreed that Object.freeze and Object.seal will not reconfigure private named properties. Yes. Given our current stable of APIs, reconfiguring a private named property requires use of Object.defineProperty by someone who knows the private name. Do you think that Date will need an additional method that makes the time value immutable? That would work. It would also work to expose this name directly, so that it is in effect not private within its context. For this particular case, another possibility is perhaps lighter weight. Once you explain the internal property as a privately named property, you can explain that all the internal property of Date.prototype is a non-configurable non-writable privately named property with value NaN, as if by Object.defineProperty. Do we need to establish a convention for objects that want to enable public facing immutability requests? Note that immutability may not necessarily be the same thing as frozen or sealed. I can imagine situations (Date.prototype is a good example) where you would want to make an object immutable but still allow additions/modifications of methods or other new properties. I would like to see general support for immutability for many reasons. But you seem to mean something different. I've been using immutable to mean approximately transitively frozen, so it would be stronger than seal or freeze. I have postponed voicing my desire for general immutability support since it raises a variety of hard issues which would definitely exceed our budget for ES6. Even if above you mean general support only for freezing privately named properties, I expect many of these hard problems to arise as well. But yes, we should start talking about it. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Freezing private state (was: Rationale behind supporting Invalid Date)
On Tue, Feb 14, 2012 at 5:48 PM, Mark S. Miller erig...@google.com wrote: named property, you can explain that all the internal property of Date.prototype is a non-configurable non-writable privately Should be ...you can explain the internal... -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Feb 14, 2012, at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com
wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org
wrote:
See the thread containing Dean Landolt's dissent on 'length' being the
best
name:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html
The January 19 2012 meeting notes recorded here:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
include At next meeting MarkM will present a tiny API proposal for
maps
and
sets.
In today's practice, iterables are ducktyped by the presence of a
length property.
IME they're ducktyped by the presence of forEach (this is far from
perfect).
Length has nothing to do with iterability. What about generators?
I don't want to go looking anything up right now, but I have lots of
memories of things looking for the presence of length to denote an
array-like.
Not only that, `length` is how ES's own Array methods control iteration.
What does that have to do with ducktyping an array? All kinds of objects
have length properties -- it'd be foolish to assume you have an array-like
with nothing more than an object w/ a length.
[].forEach.call({ 0: bar, 1: qux }, function(val) {
console.log(val); });
undefined
[].forEach.call({ 0: bar, 1: qux, length: 2 }, function(val) {
console.log(val); });
bar
qux
undefined
Yes, length is used to denote the existence of an enumeration. The only
thing this has to do with iteration is that enumerations are iterable.
The closest thing we have to an iteration protocol in es5 is forEach and
friends -- if you have an object with forEach you know you've got some kind
of iterable.
I don't think an [implication of] metric
topology matters to basically anyone who's not a huge language-design
nerd. ^_^
I'm pretty sure math geeks would disagree.
We math geeks are also thin on the ground, so the point of my
assertion (that the number of people who care is vanishingly small)
still holds.
Additionally, having multiple names for the size of property makes
it more difficult to learn, and more difficult to create generic code.
That's a bold assertion. I'd argue that having two different names for
two
things that are fundamentally different is quite practical. It's
especially
useful for writing generic code ;)
They're not fundamentally different unless you go to some lengths (pun
not intended) to make them so. length is the size of a collection;
it doesn't immediately denote anything about the indexability of said
collection.
But more practically we need different names -- setting length has
certain
expectations that wouldn't hold across all collections. Violating these
expectations would make things ever more difficult to learn...and
generic
code even harder to write.
This sounds pretty reasonable. The fact that 'length' is settable on
Array is pretty weird in the first place imo,
If you think of `length` in terms of measuring a physical thing, it's
not weird at all.
The fact that it shaves off array tails is a little weird though, right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 8:50 PM, Dean Landolt d...@deanlandolt.com wrote:
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Feb 14, 2012, at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com
wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org
wrote:
See the thread containing Dean Landolt's dissent on 'length' being
the
best
name:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html
The January 19 2012 meeting notes recorded here:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
include At next meeting MarkM will present a tiny API proposal for
maps
and
sets.
In today's practice, iterables are ducktyped by the presence of a
length property.
IME they're ducktyped by the presence of forEach (this is far from
perfect).
Length has nothing to do with iterability. What about generators?
I don't want to go looking anything up right now, but I have lots of
memories of things looking for the presence of length to denote an
array-like.
Not only that, `length` is how ES's own Array methods control iteration.
What does that have to do with ducktyping an array?
Apologies, I was actually responding to Length has nothing to do with
iterability, wherein `length` plus numeric index has everything to do with
the ability to iterate (as far as the Array methods are concerned). I'm not
saying that law has to apply to Map and Set.
All kinds of objects have length properties -- it'd be foolish to assume
you have an array-like with nothing more than an object w/ a length.
Agreed.
[].forEach.call({ 0: bar, 1: qux }, function(val) {
console.log(val); });
undefined
[].forEach.call({ 0: bar, 1: qux, length: 2 }, function(val) {
console.log(val); });
bar
qux
undefined
Yes, length is used to denote the existence of an enumeration.
The only thing this has to do with iteration is that enumerations are
iterable.
The closest thing we have to an iteration protocol in es5 is forEach and
friends -- if you have an object with forEach you know you've got some kind
of iterable.
That's just as flimsy as the assumption that anything with `length` is
iterable, right?
{ forEach: function() {} }
I don't think an [implication of] metric
topology matters to basically anyone who's not a huge language-design
nerd. ^_^
I'm pretty sure math geeks would disagree.
We math geeks are also thin on the ground, so the point of my
assertion (that the number of people who care is vanishingly small)
still holds.
Additionally, having multiple names for the size of property makes
it more difficult to learn, and more difficult to create generic code.
That's a bold assertion. I'd argue that having two different names for
two
things that are fundamentally different is quite practical. It's
especially
useful for writing generic code ;)
They're not fundamentally different unless you go to some lengths (pun
not intended) to make them so. length is the size of a collection;
it doesn't immediately denote anything about the indexability of said
collection.
But more practically we need different names -- setting length has
certain
expectations that wouldn't hold across all collections. Violating these
expectations would make things ever more difficult to learn...and
generic
code even harder to write.
This sounds pretty reasonable. The fact that 'length' is settable on
Array is pretty weird in the first place imo,
If you think of `length` in terms of measuring a physical thing, it's
not weird at all.
The fact that it shaves off array tails is a little weird though, right?
When I shorten the length of something, unless I've specifically asked for
it, it should be discarded. Like haircuts, or fabric. All I'm saying is
that I disagree that it's in any way weird. You're welcome to disagree
and hold onto that, but I'm never going to agree that any aspect of
`length` is weird.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Tue, Feb 14, 2012 at 12:23 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: nope, Set does not even accept arguments as it is now ... does it ? Not now. But this thread suggests changing it to do so. I think I agree but don't yet have a strong opinion about whether Set should have a single iteratable parameter or a rest parameter of the individual elements. Relevant question: What should spread (... in a call expression) do when its operand is an iterator or iteratable? Currently spread simple treats its operand as array-like, in which case I think perhaps Set should stick with a single parameter. If we can generalize spread to enumerate the values obtained from an iterator, then I think perhaps Set should go with the spread parameter. Whatever we decide for Set should also guide what we do for Map and WeakMap of course. On Tue, Feb 14, 2012 at 9:20 PM, Dean Landolt d...@deanlandolt.comwrote: On Tue, Feb 14, 2012 at 3:07 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? `Set(1, 2, 1)` then? Are you suggesting this should throw? So you'd need to dedupe your arguments before you construct a set with them? Isn't that a primary use case of sets? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.comwrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Freezing private state (was: Rationale behind supporting Invalid Date)
On Feb 14, 2012, at 5:48 PM, Mark S. Miller wrote: On Tue, Feb 14, 2012 at 11:08 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: My current intent is to respecify the Date time value slot as a private named property rather than as an internal property. This will enable freezing of that property as well as enabling subclassing of Date. ... Do you think that Date will need an additional method that makes the time value immutable? That would work. It would also work to expose this name directly, so that it is in effect not private within its context. For this particular case, another possibility is perhaps lighter weight. Once you explain the internal property as a privately named property, you can explain that all the internal property of Date.prototype is a non-configurable non-writable privately named property with value NaN, as if by Object.defineProperty. Specifying the attributes works for Date.prototype, but programmer might want to make the private time value property of some other Date objects be non-writable, non-configurable. Making the private name of the property problem seems like an undesirable way to enable that. Do we need to establish a convention for objects that want to enable public facing immutability requests? Note that immutability may not necessarily be the same thing as frozen or sealed. I can imagine situations (Date.prototype is a good example) where you would want to make an object immutable but still allow additions/modifications of methods or other new properties. I would like to see general support for immutability for many reasons. But you seem to mean something different. I've been using immutable to mean approximately transitively frozen, so it would be stronger than seal or freeze. I this case I actually meant sometime weaker. I mean that the value state of the object can not be modified. For example, like the string value state of an String object or the number value state of a Number object. Public properties can still be added to such objects. (Perhaps all properties frozen but the object is still extensible is a close to what I have in mind.) What exactly constitutes the value state of any particular object will vary according to what is being modeled by the object. However, I suspect ES style will move in a direction where often such value state is represented using private named properties. I have postponed voicing my desire for general immutability support since it raises a variety of hard issues which would definitely exceed our budget for ES6. Even if above you mean general support only for freezing privately named properties, I expect many of these hard problems to arise as well. But yes, we should start talking about it. I assume some of the difficulties relate to specific invariants you might want to apply to all of your immutable objects. I'm not thinking of any such invariants, instead I would view the meaning of what I mean by immutability to be defined by each object abstraction. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Tue, Feb 14, 2012 at 9:17 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Feb 14, 2012 at 8:50 PM, Dean Landolt d...@deanlandolt.comwrote:
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Feb 14, 2012, at 4:20 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt d...@deanlandolt.com
wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org
wrote:
See the thread containing Dean Landolt's dissent on 'length' being
the
best
name:
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018571.html
The January 19 2012 meeting notes recorded here:
https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html
include At next meeting MarkM will present a tiny API proposal for
maps
and
sets.
In today's practice, iterables are ducktyped by the presence of a
length property.
IME they're ducktyped by the presence of forEach (this is far from
perfect).
Length has nothing to do with iterability. What about generators?
I don't want to go looking anything up right now, but I have lots of
memories of things looking for the presence of length to denote an
array-like.
Not only that, `length` is how ES's own Array methods control iteration.
What does that have to do with ducktyping an array?
Apologies, I was actually responding to Length has nothing to do with
iterability, wherein `length` plus numeric index has everything to do with
the ability to iterate (as far as the Array methods are concerned). I'm not
saying that law has to apply to Map and Set.
All kinds of objects have length properties -- it'd be foolish to assume
you have an array-like with nothing more than an object w/ a length.
Agreed.
[].forEach.call({ 0: bar, 1: qux }, function(val) {
console.log(val); });
undefined
[].forEach.call({ 0: bar, 1: qux, length: 2 }, function(val) {
console.log(val); });
bar
qux
undefined
Yes, length is used to denote the existence of an enumeration.
The only thing this has to do with iteration is that enumerations are
iterable.
The closest thing we have to an iteration protocol in es5 is forEach and
friends -- if you have an object with forEach you know you've got some kind
of iterable.
That's just as flimsy as the assumption that anything with `length` is
iterable, right?
{ forEach: function() {} }
I'd say less so, but yeah, not by all that much :)
I don't think an [implication of] metric
topology matters to basically anyone who's not a huge
language-design
nerd. ^_^
I'm pretty sure math geeks would disagree.
We math geeks are also thin on the ground, so the point of my
assertion (that the number of people who care is vanishingly small)
still holds.
Additionally, having multiple names for the size of property makes
it more difficult to learn, and more difficult to create generic
code.
That's a bold assertion. I'd argue that having two different names
for two
things that are fundamentally different is quite practical. It's
especially
useful for writing generic code ;)
They're not fundamentally different unless you go to some lengths (pun
not intended) to make them so. length is the size of a collection;
it doesn't immediately denote anything about the indexability of said
collection.
But more practically we need different names -- setting length has
certain
expectations that wouldn't hold across all collections. Violating
these
expectations would make things ever more difficult to learn...and
generic
code even harder to write.
This sounds pretty reasonable. The fact that 'length' is settable on
Array is pretty weird in the first place imo,
If you think of `length` in terms of measuring a physical thing, it's
not weird at all.
The fact that it shaves off array tails is a little weird though, right?
When I shorten the length of something, unless I've specifically asked for
it, it should be discarded. Like haircuts, or fabric. All I'm saying is
that I disagree that it's in any way weird. You're welcome to disagree
and hold onto that, but I'm never going to agree that any aspect of
`length` is weird.
Perhaps I should have said *possibly surprising*, especially in light of
the fact that you can't subtype array and couldn't otherwise emulate the
behavior pre-es5.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
Tab Atkins Jr. wrote: IME they're ducktyped by the presence of forEach (this is far from perfect). Length has nothing to do with iterability. What about generators? I don't want to go looking anything up right now, but I have lots of memories of things looking for the presence of length to denote an array-like. Array-like != iterable. Eager length is a problem for lazy lists (iterators). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
Brendan Eich wrote: Tab Atkins Jr. wrote: IME they're ducktyped by the presence of forEach (this is far from perfect). Length has nothing to do with iterability. What about generators? I don't want to go looking anything up right now, but I have lots of memories of things looking for the presence of length to denote an array-like. Array-like != iterable. But I should have written Array-like : Iterable /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Feb 14, 2012, at 6:34 PM, Mark S. Miller wrote: On Tue, Feb 14, 2012 at 1:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: I don't want to go looking anything up right now, but I have lots of memories of things looking for the presence of length to denote an array-like. In ES5: Many of the the Array.prototype methods, including all of the Array extras use length based iteration of array indexed properties and will work with all array-like objects. apply uses length based iteration of array indexed properties The arguments object is array-like (length property and array indexed element properties) The match object return by RegExp exec is array-like String objects are array-like In the ES6 draft, so far the spread operator uses length based iteration of array indexed properties In all of the above contexts, array-like means that the ToInteger value of the length property is one more than the largest valid array index property (in ES5 a Uint32 value). Array-like processing of an object means iterating over it array index properties from 0 to length-1. Where or not holes are skipped or processed (as undefined) depends upon upon the specific algorithm. Object without a length property are seen as having a length value of 0. (ToInteger(undefined) yields 0) and hence always perform 0 iterations If someone does look for examples, this would be helpful. The issue is array-like in what ways? Other than being iteratable, Sets and Maps aren't array-like in any other way I can think of. And iteratable is new with ES6 so that can't be the commonality. OTOH, functions have a length and they aren't array like in any way I can fathom. The possible confusion with functions may have already deterred people from duck typing on length. If you used a function object in a context where an array-like is required is will be treated as having holes for its array indexed properties up to its length value -1. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Jason Orendorff wrote: I don't think that has ever happened. Python hash codes differ from version to version and from OS to OS. Jython has a completely different hashing function from CPython, even for strings. Keep in mind that hash tables are one of two core data structures in Python, so if code could sanely depend on iteration order, it would. Is this comparable with JS? Interop on the web is a harsh mistress. The C-Python vs. IronPython vs. PyPy vs. etc. situation is more of a porting model with one-way forks. Mark Miller is holding up the argument for determinism really well. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. Agreed. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Tue, Feb 14, 2012 at 10:13 PM, Brendan Eich bren...@mozilla.org wrote: Is this comparable with JS? Interop on the web is a harsh mistress. The C-Python vs. IronPython vs. PyPy vs. etc. situation is more of a porting model with one-way forks. Java seems comparable, in that compiled code is expected to run on different JVMs. I'm not aware of any Java code that relies on a particular iteration order where it is unspecified in the API. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
FWIW: I like that you can expressly opt in to ordered iteration in Java, by using LinkedHashSet (which is a subclass of HashSet which implements the interface Set): http://docs.oracle.com/javase/6/docs/api/java/util/LinkedHashSet.html On Feb 15, 2012, at 4:32 , John Tamplin wrote: On Tue, Feb 14, 2012 at 10:13 PM, Brendan Eich bren...@mozilla.org wrote: Is this comparable with JS? Interop on the web is a harsh mistress. The C-Python vs. IronPython vs. PyPy vs. etc. situation is more of a porting model with one-way forks. Java seems comparable, in that compiled code is expected to run on different JVMs. I'm not aware of any Java code that relies on a particular iteration order where it is unspecified in the API. -- John A. Tamplin Software Engineer (GWT), Google ___ 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 constructor arguments
+1 on ... (spread) exhausting an iterator to expand the iterated values into positional parameters or initialisers. /be Mark S. Miller wrote: On Tue, Feb 14, 2012 at 12:23 PM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: nope, Set does not even accept arguments as it is now ... does it ? Not now. But this thread suggests changing it to do so. I think I agree but don't yet have a strong opinion about whether Set should have a single iteratable parameter or a rest parameter of the individual elements. Relevant question: What should spread (... in a call expression) do when its operand is an iterator or iteratable? Currently spread simple treats its operand as array-like, in which case I think perhaps Set should stick with a single parameter. If we can generalize spread to enumerate the values obtained from an iterator, then I think perhaps Set should go with the spread parameter. Whatever we decide for Set should also guide what we do for Map and WeakMap of course. On Tue, Feb 14, 2012 at 9:20 PM, Dean Landolt d...@deanlandolt.com mailto:d...@deanlandolt.com wrote: On Tue, Feb 14, 2012 at 3:07 PM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? `Set(1, 2, 1)` then? Are you suggesting this should throw? So you'd need to dedupe your arguments before you construct a set with them? Isn't that a primary use case of sets? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.com mailto:petermich...@gmail.com wrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. Peter ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org mailto: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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
set.empty() method
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
Perhaps I am overly fatalistic here, but if we don't specify an iteration order I think the web will just go and specify it for us, as it has for object property iteration order. We can bet against history repeating itself if we wish. On Feb 14, 2012, at 7:13 PM, Brendan Eich wrote: Mark Miller is holding up the argument for determinism really well. I'm not sure anyone disagrees with his points. We should look into deterministic data structures and measure the performance. Agreed. *nod. On Feb 13, 2012, at 6:03 PM, Mark S. Miller 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. Mark, Do you think we want strict insertion order, including for numeric index properties? I guess I'm thinking the obvious here ( http://wiki.ecmascript.org/doku.php?id=strawman:enumeration ), but it would seem a simplest for users if there were a single story for iteration order. cheers, G. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very inefficient.
set.forEach(function(element) {
set['delete'](element);
});
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
Re: Set iterators
On Tue, Feb 14, 2012 at 10:05 PM, Gavin Barraclough barraclo...@apple.comwrote: [...] Mark, Do you think we want strict insertion order, including for numeric index properties? I guess I'm thinking the obvious here ( http://wiki.ecmascript.org/doku.php?id=strawman:enumeration ), but it would seem a simplest for users if there were a single story for iteration order. Great question. I hadn't thought about that in this context, but I do find it attractive. Ironically, this might be less efficient than pure insertion order. But worrying about that too early without measurement or evidence would again be premature. It also accommodates Allen's specialized collection as simply a degenerate case. Cool. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
clear() is ok. Also, java.util.Map and java.util.Set use clear() so it
would also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon a...@ashannon.us wrote:
I'd agree with using clear() and isEmpty() with their respective actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich bren...@mozilla.org wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
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
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
deleteAll() seems confusing because (even though sets aren't designed
like this) it seems like deleteAll(key) would delete all entries that
are mapped from key.
On Wed, Feb 15, 2012 at 00:47, Mark S. Miller erig...@google.com wrote:
clear() is ok. Also, java.util.Map and java.util.Set use clear() so it would
also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon a...@ashannon.us wrote:
I'd agree with using clear() and isEmpty() with their respective actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich bren...@mozilla.org wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
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
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
--
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
