Note that I did **not** add a new member in the vtbl: I couldn't find a use for it. I mean, sure, I can use it instead of checking for typed arrays but I think that's overkill since it's only two places (find_prop_name and jsdisp_define_property), and both would need two separate member functions in the vtbl in this regard. I don't think it's worth it.
It depends how far do we want to go with it. Ideally we wouldn't allocate `dispex_prop_t` even for properties that are queried with `GetDispID` and it may be easier to just never allocate them at all. In that case, it would be an alternative to `find_prop_name`, not something to use in it. We usually need it to get some information about the property and in that sense, an interface similar to `jsdisp_get_own_property` should be enough for most cases. We don't need the actual `dispex_prop_t` when the object is able to provide its description and get/set operations. Enumeration may be a bit tricky, but it seems doable as well.
It could be limited to indexed properties or not, if it's helpful for MSHTML bindings too. I can't really comment on that part without seeing the code.
For DISPIDs, we could allocate a pool for 'indexed' or 'custom' properties (like we do in MSHTML) or something along those lines. To handle cases which allow overriding properties, the whole thing may indeed be a fallback for `find_prop_name`.
- The first special case is that they override any positive index, even if out of bounds. However, they **do** have bounds. The suggested override of `idx_length` to handle all indices does not work, because for instance when obtaining an ID or when testing if a prop "exists" (hasOwnProperty), they would be reported as available, even though they're **not**. A Typed Array with 5 elements does **not** have the property "10", even though you cannot redefine it. You also cannot access a prototype's "10" prop with it because, even if it doesn't exist and is out of bounds, it's still intercepted!
Yes, that's why I suggested a new function querying the property: you could just return an error from it for invalid indexes.
The third special case is when defining a Typed Array prop. For out of bounds, as previously mentioned, it's simply ignored. But for props that do exist, they act as _setters_, which is completely unlike normal props. That is, defining a prop does coerce the value into the typed array's type! And defining accessors simply throws an error. This is handle in jsdisp_define_property as a special case.
It's not that special. If you consider those properties as a non-configurable properties, then the same checks as we do in `jsdisp_define_property` would explain it. For changing the type, even the existing `idx_put` should be enough.