- 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