Re: Lazy interface objects?

On 9/21/11 9:59 AM, Jonas Sicking wrote:
> One solution might be to implement the global using a proxy. There's a
> lot of magic in the global (including its array-like behavior), so you
> might want to do that for other reasons anyway.
>
> / Jonas
>
> On Wed, Sep 21, 2011 at 9:51 AM, Travis Leithead
> <Travis.Leithead@microsoft.com>  wrote:
>> I'd rather not relax the spec on this point. Many of the ES built-ins (Array, Object, Number, etc.) have the same issue (although there are far fewer of these interface objects) and for compatibility the ES5 spec keeps these objects as [[writable]]: true.
>>
>> The reason WebIDL is defined this way is to keep ES5 and the DOM interface objects consistent in this manner.
>>
>> For an implementation that wants to optimize the way you describe, they would want to come up with mechanism that would be inclusive of built-in ES objects as well as DOM interface objects (as we did in IE9).
>>
>> -Travis
>>
Travis:

For pure-JS implementations of the DOM, I'm not sure that any such 
mechanisms to enable lazy interface initialization exist.  Given the 
choice between initializing all interfaces at load time and a minor 
divergence from the spec (the property is an accessor property if 
observed before being read but converts to a data property the first 
time it is read) I suspect I'd end up diverging from the spec.

I wonder if the ES3 requirement of [[Writable]] properties was 
reconsidered during the development of ES5 and the addition of 
Object.defineProperty and Object.getOwnPropertyDescriptor()?  In ES3 
implementations that supported getters and setters, the choice between a 
data property and an accessor property was an implementation detail.  
When ES5 added getOwnPropertyDescriptor(), that implementation detail 
became observable, and the meaning of a [[Writable]]:true requirement 
changed from a behavior to be tested (can I set the property?) to an 
attribute to be queried (what does getOwnPropertyDescriptor() return?).  
Was there an explicit intent there to restrict the choices available to 
implementors?  If not, then maybe the ES spec should be relaxed in the 
same way that I'm proposing that WebIDL should be relaxed.  (Though I 
don't think the case for relaxing ES is as strong).

In general, it seems to me that defineProperty and 
getOwnPropertyDescriptor are reflection and metaprogramming tools that 
intentionally enable unsafe observation of implementation details.  It 
is a mistake, I think, to use them as a specification mechanism.  (The 
same thing goes for getPrototypeOf)

Jonas:

So far, I'm concentrating on the DOM and have not really though about 
the global object.  Maybe when dom.js is used in some special embedding 
of spidermonkey, I'll be able to proxy the global object.  But for a 
pure JS DOM, without special embedding I don't think that using a proxy 
for the global object is possible.

     David

     David


>> -----Original Message-----
>> From: public-script-coord-request@w3.org [mailto:public-script-coord-request@w3.org] On Behalf Of David Flanagan
>> Sent: Tuesday, September 20, 2011 9:48 PM
>> To: public-script-coord@w3.org
>> Subject: Lazy interface objects?
>>
>> When an specification, such as HTML, defines many IDL interfaces, implementors are naturally tempted to create the interface objects lazily so that they are only initialized when first used.
>>
>> One way to do that is to define an interface object property (such as the HTMLHeadingElement property of the Window object) using a getter which when invoked, initializes the HTMLHeadingElement interface object, converts the property to a data property with that object as its value and returns the object.
>>
>> Unfortunately, the first paragraph of WebIDL §4.5 requires an interface object property to be [[Writable]]: true.  Thus, it seems that using a getter for the property would not conform.  Can the spec be relaxed on this point?  It seems that the relevant detail is that the property can be set: that it should be a writable data property or a accessor property with a setter.
>>
>> (Thanks to David Bruant for pointing this out.  See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=687042 for context.)
>>
>>      David Flanagan
>>
>>
>>
>>

Received on Wednesday, 21 September 2011 19:50:53 UTC