Please prefix getter/setter/callback interface with legacy so it's clear they are

[annevk]

This cannot be fixed soon enough. Apparently we now have RTCIdentityProvider as callback interface? That should never have been added to the platform. We should really mark all the getter/setter/callback interface/etc. stuff as legacy so it's not used.

[bzbarsky]

Why is callback interface supposed to be legacy? Except for the single-function case (which should use a callback instead), its a perfectly reasonable API design. The other option is a list of callbacks, which has its own benefits and drawbacks.

Note that the consumer can shim a "list of callbacks" interface on top of a callback interface by creating a dummy object, just like one can shim a "callback interface" interface on top of a list of callbacks by binding all the methods to the "this" object and passing them in. So in practice the API design choice should be mostly informed by how many callbacks there are and whether it makes sense to have them be methods of a single object conceptually.

For the case of one callback, clearly just a callback function is better. For two callbacks, unclear. For 10 callbacks, I would argue that a callback interface is a much better representation than a flat list; at least as an API consumer I would prefer to not have to count my function arguments to see which one is which.

[bzbarsky]

Ah, I see the suggestion for dictionary of callbacks in the other bug. That's probably good enough, yeah... Can't do getters or setters that way, but survivable.

[foolip]

It seems like a big plus with dictionaries that the members are evaluated immediately, but are there reasons to ever prefer the "lazy" behavior of callback interfaces?

It looks within reach to limit callback interfaces to the three existing cases, which are all single-function cases.

[jan-ivar]

One reason might be to not put on the user to remember to .bind(this) on every callback.

[annevk]

@jan-ivar most callbacks don't require that at all.

[jan-ivar]

Right, I didn't mean all callbacks, I meant every callback in a particular interface that now has to register its methods, like w3c/webrtc-pc#559 (comment).

Not saying it's a big reason, but since we were asking.

[annevk]

Note: WebRTC got fixed.

[tobie]

Worth noting somewhere that the only Legacy callback interface object is NodeFilter.

[annevk]

That's the only one with constants. EventListener is another and I think there might be more.

[tobie]

Yeah. There are more callback interfaces but just one legacy callback interface object.

[annevk]

No, they're all legacy.

[tobie]

Yeah, they're all legacy, but only NodeFilter is a Legacy callback interface object.

[RByers]

Is it really true that getter/setter is "legacy" and discouraged in new APIs? Can anyone provide a reference for this documenting the extent of the consensus here? In the absence of agreed upon guidance (eg. captured concretely in the webidl spec), I'm personally not willing to block requests to ship such new APIs in blink (such as Typed OM).

/cc @ajklein @foolip @chrishtr

[bzbarsky]

I think there is general agreement that named getters/setters are a bad idea.

For indexed getters/setters, things are complicated, not least because there are legitimate use cases that have no other solutions right now. Indexed setters do require some careful spec prose around out-of-bounds sets.

[bzbarsky]

One other thing. I think there is a large camp that considers some of the API goals of Typed OM as currently specified to be broken by design. Not the actual functionality, but the use of typing and typechecking. I personally am not in this camp, so I do not want to speak for it, but just wanted to mention its existence. This is part of the issue you are encountering with pushback on the Typed OM use of indexed getters/setters.

[RByers]

For indexed getters/setters, things are complicated, not least because there are legitimate use cases that have no other solutions right now. Indexed setters do require some careful spec prose around out-of-bounds sets.

Thanks. This case is indexed getters / setters only.

I think there is a large camp that considers some of the API goals of Typed OM as currently specified to be broken by design. Not the actual functionality, but the use of typing and typechecking. I personally am not in this camp, so I do not want to speak for it, but just wanted to mention its existence. This is part of the issue you are encountering with pushback on the Typed OM use of indexed getters/setters.

Thanks for the heads up. Can you point to anywhere that this feedback has been given publicly? I didn't come across it when scanning the open issues or initial TAG feedback, but I only did a quick scan so I may have missed it.

[bzbarsky]

I don't have links offhand, sorry. It's the general "should there be eager or lazy typechecking" problem that's been discussed a few times on es-discuss and public-script-coord. And probably in person in TC39 and private discussions....

Some of this is referenced in the long discussion at #345 (again, no links there). There are references to it in the TAG feedback issue.

[tabatkins]

some of the API goals of Typed OM as currently specified to be broken by design. Not the actual functionality, but the use of typing and typechecking.

And note, of course, that this isn't a special goal of Typed OM, it's part and parcel of literally all of WebIDL.

I think there is general agreement that named getters/setters are a bad idea.

For indexed getters/setters, things are complicated, not least because there are legitimate use cases that have no other solutions right now. Indexed setters do require some careful spec prose around out-of-bounds sets.

I strongly agree that named getters/setters should be considered legacy and/or given a name that clearly demonstrates they're special-use and should have thoro review of the necessity. Maps satisfy all their use-cases much better.

For indexed getters/setters, yeah, I'm finding there's a lot of missing guidance on how to do these right. :(