Intercepting sets on array-like objects

[Tab Atkins Jr.]

On Fri, Jun 9, 2017 at 2:07 PM, Domenic Denicola <d at domenic.me> 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