7

While looking over new changes to JavaScript I noticed that Set and Map use .size instead of .length like arrays would.

This seems like a pointless diversion from what's normal with arrays - just one more thing to remember.

Was there a good design reason for this?

jocull
  • 17,542
  • 18
  • 95
  • 139
  • 1
    My guess is that sets and maps are not really considered one-dimensional vectors *(having a "length")* of items, like arrays are. Would you consider it bad to also name the size of a heap or a stack something other than `length`? – Anders Marzi Tornblad Jan 27 '16 at 13:33
  • 6
    This is a good question that will answer yours. http://stackoverflow.com/questions/300522/count-vs-length-vs-size-in-a-collection – Michael Warner Jan 27 '16 at 13:39
  • 1
    In the case of Set at least, if you look at the spec, the main difference as opposed to Array's length is that size is recalculated each time you call it. Now I'm not sure that's the main reason for naming it differently, and I actually doubt it. – bug-a-lot Jan 27 '16 at 13:40
  • @bug-a-lot Not necessarily - further up the spec it also says _"The data structures used in this Set objects specification is only intended to describe the required observable semantics of Set objects. It is not intended to be a viable implementation model."_ the size could be cached when things are added etc. – James Thorpe Jan 27 '16 at 13:41
  • @JamesThorpe Yep, there's no surprise there. As I was writing the answer I was actually thinking that no one in their right mind would actually implement it the way it's being exemplified in the spec. – bug-a-lot Jan 27 '16 at 13:42

2 Answers2

13

There's a lot of discussion in the esdiscuss thread "Set length property". This was a hotly debated issue, so it's not surprising that you do not necessarily agree with the resolution.

There is a tremendous amount of arguing about this in esdiscuss. Ultimately, the argument that prevailed (as evidenced by the fact that ES2015's Sets have size and not length) was summarized in a post by David Bruant:

...for me 'length' refers to a measurement with something like a ruler. You start at 0 and see up to where it goes. This is very accurate for an array which is an indexed set (starting at 0 and growing) and for arrays as considered in C (continuous sequence of bytes) which ECMAScript arrays seem inspired of. This is probably less relevant for unordered collections such as sets which I'd tend to consider as a messy bag.

And further discussed in a post by Dean Landolt:

Just wanted to jump in and say non-writable length is consistent with String behavior as well, but David makes a good point about length implying metric topology. David's suggestion of count is nice. ISTM what we're talking about is cardinality, but no need to get too silly w/ precision. Though size is just fine with me, and has plenty of prior art.

Bergi
  • 513,640
  • 108
  • 821
  • 1,164
apsillers
  • 101,930
  • 15
  • 206
  • 224
  • This is the only reasonable answer to the question really. I wonder if anyone has thought about doing a project that annotates the specification with links to where things were discussed... hmm... – James Thorpe Jan 27 '16 at 13:49
0

While apsillers' Jan 27, 2016 answer adds great links, a code example is missing. The size of a set is a read-only getter while that's not the case for arrays which allow modifying the length to truncate the array.

let arr = [1, 2, 3, 4]
arr.length = 2
console.log("modified length array", arr) // [1, 2]

let mySet = new Set([1, 2, 3, 4])
mySet.length = 2
mySet.size = 2
console.log("modified length set", [...mySet]) // [1, 2, 3, 4]

let str = "1234"
str.length = 2
console.log("modified length string", str) // "1234"
ubershmekel
  • 9,570
  • 6
  • 62
  • 78