Make [SameObject] beneficial

[annevk]

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.

[annevk]

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]

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]

Yes, I agree.

[inexorabletash]

+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 keyPath attributes, but they can produce string or Array-of-string results. So if we can drop the restriction requiring the type to be object or an Interface, I'd like that too.

[bzbarsky]

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]

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]

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]

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.