On Tue, Feb 14, 2012 at 9:17 PM, Rick Waldron <[email protected]>wrote:
> > > On Tue, Feb 14, 2012 at 8:50 PM, Dean Landolt <[email protected]>wrote: > >> >> >> On Tue, Feb 14, 2012 at 8:14 PM, Rick Waldron <[email protected]>wrote: >> >>> On Feb 14, 2012, at 4:20 PM, "Tab Atkins Jr." <[email protected]> >>> wrote: >>> >>> > On Tue, Feb 14, 2012 at 1:10 PM, Dean Landolt <[email protected]> >>> wrote: >>> >> On Tue, Feb 14, 2012 at 3:54 PM, Tab Atkins Jr. <[email protected] >>> > >>> >> wrote: >>> >>> On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich <[email protected]> >>> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
