Set length property
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
include "At next meeting MarkM will present a tiny API proposal for maps and sets."
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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.
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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.
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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".
On Tue, Feb 14, 2012 at 4:20 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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.
On Feb 14, 2012, at 4:20 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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.
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Feb 14, 2012, at 4:20 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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,
lengthis 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
lengthin 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?
On Tue, Feb 14, 2012 at 8:50 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Feb 14, 2012, at 4:20 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the
best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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,
lengthis 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
lengthin 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".
On Tue, Feb 14, 2012 at 1:20 PM, Tab Atkins Jr. <jackalmage at 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.
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".
OTOH, some bozo (me) once proposed < conventions:isarraylike>. Hopefully
no one followed my advice ;).
On Tue, Feb 14, 2012 at 9:17 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Tue, Feb 14, 2012 at 8:50 PM, Dean Landolt <dean at deanlandolt.com>wrote:
On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
On Feb 14, 2012, at 4:20 PM, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <dean at deanlandolt.com> wrote:
On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <jackalmage at gmail.com
wrote:
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
See the thread containing Dean Landolt's dissent on 'length' being the
best name:
esdiscuss/2011-November/018571
The January 19 2012 meeting notes recorded here:
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,
lengthis 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
lengthplus 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
lengthis 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
lengthin 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
lengthis "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.
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).
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
On Feb 14, 2012, at 6:34 PM, Mark S. Miller wrote:
On Tue, Feb 14, 2012 at 1:20 PM, Tab Atkins Jr. <jackalmage at 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.
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <brendan at mozilla.org> wrote:
The January 19 2012 meeting notes recorded here:
include "At next meeting MarkM will present a tiny API proposal for maps and sets."
Has this meeting happened yet? If so are the results about Map and Set posted somewhere?
Thanks, Peter
Dave and I decided to collaborate on this and will present it at the May meeting. So no, not yet.
As always, suggestions welcome.
I listed quite a few suggestions in a variety of emails to this list. I think this is a list of all of them...
esdiscuss/2012-February/020460, esdiscuss/2012-February/020480, esdiscuss/2012-February/020481, esdiscuss/2012-February/020483, esdiscuss/2012-February/020523, esdiscuss/2012-February/020575, esdiscuss/2012-February/020607, esdiscuss/2012-February/020609
Set union, difference, and intersection methods were in one post but I don't see that in the archives.
Peter
In the proposal, set objects have no length property. It is common to want to know the length of a set.
harmony:simple_maps_and_sets
For example, it would be good to be able to do the following.
var s = new Set(); s.add('alpha'); s.add('beta'); s.length; // 2
Peter
In the proposal, set objects have no length property. It is common to want to know the length of a set. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets For example, it would be good to be able to do the following. var s = new Set(); s.add('alpha'); s.add('beta'); s.length; // 2 Peter