On Fri, Jun 9, 2017 at 2:07 PM, Domenic Denicola <[email protected]> wrote: > I'm not really sure how you're expecting to get an answer "according to > TC39."
I was told by Anne in <https://github.com/heycam/webidl/issues/345#issuecomment-300734048> to "go back to TC39 I suppose and say you really want to do typed arrays again". (And in messages preceding/following that, Anne implies that his pushback on the idea is motivated by historical TC39 dislike for this approach.) I'm doing precisely that. > One member had replied and given his suggestion. I don't think it's a > good one for new APIs; I think new APIs should use arrays and not type check > on sets but at processing time. I'm sure there will be many other opinions > from other TC39 members. "Don't type-check things that look like arrays" means carving out a special one-off shape in web APIs - every single property set or method call in WebIDL typechecks the values. What makes "things that look like arrays" special in this regard? I can't avoid typechecking - why should specs have to do bespoke typechecking in their functions that *accept* these object, versus every other type of object in the platform that is automatically type-happy? Drilling in deeper: *fixed length* "things that look like arrays" can have type-checking in WebIDL no problem, you just have to define the names in prose, due to a legacy limitation of the WebIDL syntax. This allows users to do `obj[1] = val;` and get a TypeError thrown when it mismatches, exactly like they'd get with `obj.foo = val`. What makes fixed-length different from dynamic-length "things that look like an array"? There's no semantic/usability difference between these cases; it's purely an accidental artifact of the particular way JS handles the [] syntax. This is not good API design. Platform objects can mimic every other JS object; there's no user-understandable reason why they should be different in this one particular case. ------------ Digging back a bit to try and find what TC39 opinion Anne was referring to, I instead found this 2009 thread <https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1346.html> which might be what he is remembering (it mentions FileList and DOMTokenList), where TC39 members were pretty uniformly supportive of an "integer property catch-all" (explicitly suggested by Maciej in <https://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1354.html>) so that platform APIs could do non-live Array-likes. Did something change in the intervening 8 years? If so, what, and why? (This was the second result in my mail archives for "indexed getter", so I don't think I'm cherrypicking this thread either.) ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
