Repository navigation
Make [SameObject] beneficial #212
Description
I believe the contract with [SameObject] is supposed to be that whatever is returned the first time cannot ever change, right?
Currently specifications have to maintain that invariant and add the [SameObject] extended attribute as documentation.
However, what IDL could do instead is to allocate an internal slot when such an attribute is used. IDL's algorithm for the getter could then be to return the value from the internal slot when it's set, and when it's unset run the specification algorithm to get a value, set the internal slot to that value, and return that value.
That way the specification does not have to define how the value is stored, just how it's computed/retrieved.
Activity
annevk commentedon Oct 27, 2016
annevk commentedon Nov 9, 2016
Note that changing this will affect specifications. @bzbarsky collected a list that will need to be updated after the change: #211 (comment). Seems doable.
annevk commentedon Aug 23, 2017
Unlike [SameObject] I think we should allow this new [Cached] (or whatever we call it) extended attribute to be used for getters that return promises. That a non-cached value is returned when this is wrong seems fine.
bzbarsky commentedon Aug 29, 2017
Yes, I agree.
inexorabletash commentedon Jun 24, 2019
+1 to [Cached] - it's basically what we do in Blink, and end up writing
[SameObject, SaveSameObject]to enable autogenerated caching.Aside: I'd love to put [SameObject] on IDBObjectStore and IDBIndex's
keyPathattributes, but they can produce string or Array-of-string results. So if we can drop the restriction requiring the type to beobjector an Interface, I'd like that too.bzbarsky commentedon Jun 24, 2019
Yeah, so what Gecko has is:
[Cached]to indicate that autogenerated caching should happen. In addition to that, attributes marked[Cached]are allowed to have sequence, dictionary, and record types, because the reason for not allowing attributes with those types (creation of a new object on each get) does not apply in the[Cached]case. Also, we check that[NewObject]and[Cached]are not used together, because that's nonsensical.[SameObject]as defined in the spec, but with the additional implication that there are no side-effects from the get.[Constant]which is just like[SameObject]but without type restrictions, so you can use it on any return type. Again, implies no side-effects from the get.[Pure]which promises no side-effects but not constancy of return value. That said, two consecutive calls to a[Pure]thing will return the same value each time (because the first call can't affect the return value of the second call: see no side-effects), so[Cached]is allowed on[Pure]things, not just[Constant]/[SameObject]ones. There's a way to invalidate the cache if something that does have side-effects changes the value involved.jakearchibald commentedon Feb 15, 2023
I think it might make specs a bit hard to read, as the prose may look like it's returning a different object every time, but a sneaky bit in the IDL is changing the behaviour.
I'd rather this feature was delivered via some prose defined in infra, like: "The memoized getter steps for foo return…"
There can be an idl comment for it too, of course.
annevk commentedon Feb 15, 2023
Makes sense. I think we need both.
[Cached]results in Web IDL defining an internal slot and "getter steps" for the object and those "getter steps" would delegate to "cached getter steps" defined by the specification.jakearchibald commentedon Feb 15, 2023
WFM. Fwiw, I think "memoize" is a more accurate and well-known term when it comes to storing the result of an algorithm & returning it on future calls https://en.wikipedia.org/wiki/Memoization. But, 'cached' is fine.