Comments (12)
Should promise getters be required to use [NewObject]?
Was this meant to say [SameObject]? [NewObject] is only defined for operations and I assumed this was because that behavior is very problematic in practice for attributes. Neither is permitted by a Promise attribute.
Although there is at least one existing quirk where this doesn't hold (valueAsDate), attribute getters that cause SameValue(foo.bar, foo.bar) to always be false (i.e., with no other code in between) tend to break JS expectations, sometimes catastrophically (e.g. the old Angular diffing algorithm).
"Can use [NewObject]" isn't true for any attribute currently, regardless of its type. [SameObject] does work with attributes but specifically forbids Promise types. AFAIK it's for "fully permanent" values, i.e. never changing regardless of application state, not just never changing across consecutive accesses.
from webidl.
Was this meant to say [SameObject]? [NewObject] is only defined for operations and I assumed this was because that behavior is very problematic in practice for attributes. Neither is permitted by a Promise attribute.
No, I meant [NewObject]. (The title of the issue made me think attributes could have [NewObject].) I guess my understanding was overly simplified if even Promise typed attributes can indeed return the same Promise object multiple times. And it makes sense that they can.
In that case I think this issue can be closed as obsolete since it sounds like there are no outstanding changes to be made, wrt the title/original topic of this issue. #1077 tracks the issue about unions/objects/etc that was previously raised as a tangent of this issue.
from webidl.
Both of these extended attributes are a bit odd in that they are "pure" annotations describing high level API behavior. They have no corresponding effects in any Web IDL algorithms. They seemingly don't meet Web IDL's own definition for what an extended attribute is because they don't control behaviors that are specific to particular language bindings. That definition is likely just outdated, but like ... if you have found any of this confusing, you're right :)
from webidl.
they don't control behaviors that are specific to particular language bindings.
They actually can, though not in obvious ways. For example, in some JITs they inform things like common subexpression elimination behavior.
from webidl.
Sounds reasonable. What about linking it to http://heycam.github.io/webidl/#dfn-object-type and then adding promise types to that definition?
from webidl.
[NewObject]
has the same issue; see https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605
from webidl.
I believe [SameObject]
should also be applicable to union of interface types; the Service Worker spec certainly assumes that to be true.
from webidl.
Ping? :)
from webidl.
In https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605#c1 @bzbarsky notes that this should not just be extended to promise types, but also
It should be allowed if the return value is any object type. Specifically, any interface type, "object", a promise, an Error, a DOMException, any buffer source type, or a union of types on which [NewObject] is allowed.
from webidl.
Note that due to #217 promise getters cannot use [SameObject]
, ever.
from webidl.
Seems the spec is clear that promise getters can't use [SameObject]
and can use [NewObject]
. I've filed a separate issue #1077 for non-promise objects since those aren't covered by the title of this issue. Seems that covers everything and this issue could be closed now.
I do have one related thought though:
Should promise getters be required to use [NewObject]
? IIUC that's the behavior, and having [NewObject]
would document the behavior much more clearly.
from webidl.
That makes sense. The distinction I meant to highlight was that they describe universal properties of the operation/attribute behavior itself. Contrast e.g. PutForwards, which is defined only in terms of ES binding behavior, where any other binding (unless given its own rules for interpretting that EA) just sees a readonly attribute.
from webidl.
Related Issues (20)
- Editorial: pick JavaScript or ECMAScript and stick with it HOT 1
- 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
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.