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`.
I see. Since we map DISPIDs to indices in the props list, maybe I should place these at the upper end (signed), so first one is i.e. `2147483648 - idx_length` and so on. Not 100% sure how it will work yet since it needs a larger revamp, we'll see.
I still don't fully understand how overriding props should work, but we only really have `arguments` so far that needs it. Maybe just special casing it in there would be enough? (handling any jsval only, because it's not configurable in the first place)
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.
I tried and it doesn't work. The current checks basically replace a writable non-configurable jsval with another jsval (it can be anything, not related to the original; i.e. if original was a number, it can now be a string). It never calls prop_put or anything of the sort. For typed arrays we need strings to be coerced into the underlying type in this case, as if prop_put was called on it, instead of define_property.