New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SameObject]/[NewObject] on Promise-type attributes should be allowed #71
Comments
Sounds reasonable. What about linking it to http://heycam.github.io/webidl/#dfn-object-type and then adding promise types to that definition? |
|
I believe |
Ping? :) |
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
|
Update [SameObject] and [NewObject] to rely on it. Fixes whatwg#71 Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=27605
Note that due to #217 promise getters cannot use |
Seems the spec is clear that promise getters can't use I do have one related thought though: |
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. |
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. |
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 :) |
They actually can, though not in obvious ways. For example, in some JITs they inform things like common subexpression elimination behavior. |
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. |
Because Promise types are reference types, the [SameObject] extended attribute should be permitted for use with them. In the current spec, they are forbidden by the restriction:
4.3.15. SameObject
(Unless Promise is to be understood as an interface type.)
The text was updated successfully, but these errors were encountered: