- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 18 Oct 2012 12:11:05 -0400
- To: Travis Leithead <travis.leithead@microsoft.com>
- CC: Marcos Caceres <w3c@marcosc.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 10/18/12 11:36 AM, Travis Leithead wrote: > I naively assumed that all interface-typed objects returned the same instance > when the calling params and API behavior finds a "same" object (e.g., getAttributeNode). Not at all. Some simple counterexamples where just knowing the return type says nothing about whether a new object is created: WebGLUniformLocation? getUniformLocation(WebGLProgram? program, DOMString name); Element createElement(DOMString localName); ClientRect getBoundingClientRect(); (getBoundingClientRect doesn't clearly define its behavior, so maybe UAs don't even have interop on it). > This distinction is already clear (at least to me) when using types such as T[] vs sequence<T> and > objects that are dictionary vs. interface. What are the exceptions to this rule? The place we've found the [Creator] annotation useful in Gecko is for interface return types. In particular, we can skip some work looking up an existing JS reflection for an IDL object if we know the method always returns a new object (and actually simplify the implementation too, but that's very much a Gecko implementation detail). The place we plan to introduce a "always returns the same thing" annotation is to allow the JIT to do useful CSE and loop-hoisting. That would be useful for all sorts of getters, not just ones returning interface objects (e.g. Node.prototype.nodeType would have such an annotation). To be clear, we're adding these annotations locally in our IDL no matter what. But to the extent that these are useful to others, it would be nice if our IDL diverged as little as possible from whatever IDL specs use. And I do think there are benefits to not relying on prose to describe the "always returns a new object" behavior. -Boris
Received on Thursday, 18 October 2012 16:11:43 UTC