Re: [whatwg/webidl] ObservableArray types in namespace (#1000)

> I'll investigate this when I'm done with my current train of thought.

😍 Excited to hear more about what you find. I find several things about OA behaviors and their underlying model pretty surprising. In particular I have some thoughts to share about the way they currently implement indexed properties with custom accessor semantics (like a NodeList) instead of with custom own data property sementics (like an Array).

<details>

<summary>Perhaps the rest of this will be useful input for your investigation at least as an angle to consider. Given it’s a departure from the original topic, I’m nestling it in a &lt;details&gt;</summary>

```js
let sheet = new CSSStyleSheet();
sheet.replaceSync("* { background-color: hotpink; }");
({ __proto__: document.adoptedStyleSheets })[0] = sheet
```

That defines a "0" property _on the prototype,_ not the receiver. To fix this, the [[Set]] steps should be checking if receiver === proxy and only moving into the “like an accessor, but only when out-of-bounds” %TypedArray%-like behavior in that case specifically. But better yet, kill [[Set]] altogether! Array exotic objects themselves don’t override it for a reason: they exclusively use own-property semantics, not accessor semantics. Accessors are what [[Get]] and [[Set]] “explain”, so unless that special out-of-bounds behavior is really important, [[DefineProperty]] is normally sufficient and even [[GetOwnPropertyDescriptor]] can usually be left alone in cases like this. (It’s unfortunate that the two most specialized traps have such attractive names while the real generic ones have arcane names. “What’s a receiver? _shrug_” seems to be the most common mistake in Proxies out in the wild.)

I forget where now but I recall finding prior discussion of this where Domenic has a suspicion that this was true. He was right! However folks subsequently concluded that [[Get]] and [[Set]] were necessary. This seemed to stem from the expectation that because proxies without custom [[Set]] delegate to `target.[[Set]](P, V, Receiver)`, the custom [[DOP]] would be “skipped” if it did not have a custom implementation. This is untrue because _Receiver_ there can never be the target object if the target object isn’t exposed anywhere — it can only be an object external code can access and is almost always the proxy. It’s the receiver’s [[DOP]] that gets called in OrdinarySet if no other (unwritable / accessor) property definitions are hit on the way down and likewise it’s the receiver’s [[GOP]] and in OrdinaryGet; the receiver is the value having a property ... gotten or uhh sotten.

A user-controlled custom “typed” array only requires [[DOP]], like AEOs themselves, while a “controlled” typed array that intercepts (& possibly rejects) all mutations but preserves its own right to mutate at will additionally requires [[DOP]], [[Delete]], [[PreventExtensions]], and [[SetPrototypeOf]] (SetImmutablePrototype style) — at least if the target object is leveraged for its usual role in the proxy model. That’s the happy path for proxies, but here it’s being bypassed for reasons I haven’t been able to work out. OAs implement custom [[HasProperty]], [[Get]], [[GetOwnProperty]], [[Set]], and [[OwnKeys]], but OrdinaryX semantics for all of these would provide sound behavior for free if the forever-configurable properties were defined on the target object.

It’s super possible that I’m ignorant of / mistaken about key details & motivating design considerations that would explain the choice of accessor semantics & the reimplementation of behaviors the target object would provide out of the box if it weren’t being shunned. While I think these things _look_ like mistakes, I appreciate that this is a super difficult thing to spec and that a lot of thought’s already gone into it, so forgive me if I’m way off with this assessment.

</details>

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/issues/1000#issuecomment-1116532144

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/webidl/issues/1000/1116532144@github.com>