Comments (18)
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.
from webidl.
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.
from webidl.
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.
from webidl.
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.
from webidl.
One reason might be to not put on the user to remember to .bind(this)
on every callback.
from webidl.
@jan-ivar most callbacks don't require that at all.
from webidl.
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.
from webidl.
Note: WebRTC got fixed.
from webidl.
Worth noting somewhere that the only Legacy callback interface object is NodeFilter
.
from webidl.
That's the only one with constants. EventListener is another and I think there might be more.
from webidl.
Yeah. There are more callback interfaces but just one legacy callback interface object.
from webidl.
No, they're all legacy.
from webidl.
Yeah, they're all legacy, but only NodeFilter is a Legacy callback interface object.
from webidl.
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
from webidl.
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.
from webidl.
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.
from webidl.
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.
from webidl.
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. :(
from webidl.
Related Issues (20)
- Simple exceptions βapart from...β list is incomplete HOT 1
- Give SharedArrayBuffer a dedicated type (downstream) HOT 2
- Defining AbstractModuleSource intrinsic inheritance HOT 13
- Language-independent definition of interfaces should mention how to create instances HOT 5
- Meta: npm warnings HOT 1
- Definition name uniqueness requirement omits mixins
- Suggestion: forbid ECMA-262/402-defined global names for some named constructs HOT 2
- Nullable ObservableArray attributes are not supported HOT 1
- Make ObservableArray "subclassable" HOT 3
- Definition of {} is slightly ambiguous HOT 2
- Named properties object [[GetOwnProperty]] conflicts with class string HOT 1
- Add `toggle()` and `replace()` methods to `setlike` HOT 1
- Allowing throwing an exception with a specific message HOT 5
- Offer [[ArrayBufferDetachKey]] abstraction?
- Truncation in "convert a Web IDL arguments list to an ECMAScript arguments list" seems (potentially) incorrect
- Dictionary with required members as optional argument HOT 4
- "byte length of a buffer source type" needs updating for resizable and detached buffers HOT 9
- Intent to use BigInt/numeric union in WebNN HOT 6
- CreateMethodProperty removed from Ecma262 HOT 1
- Disallow FrozenArray<> in argument lists, and maybe dictionaries and return types HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webidl.