On Jan 30, 2012, at 11:00 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>>> Can we get rid of the concept of "Foreign Object" entirely, and just treat 
>>> all the objects we have in mind (e.g. DOM nodes) as "Built in proxy 
>>> objects"?
>> 
>> Possibly, but my gut says that is a step too far for this iteration of the 
>> spec. If we could, then we could also get rid of all internal redefinition 
>> of the internal methods and replace all chapter 15 objects specifications 
>> with Proxy based definitions.
> 
> Array is a hard case, but most of the clause 15 objects do not need to be 
> proxies, IINM. Some need private-named (formerly "internal") properties, but 
> that's a subclassing fix we want.
> 
>> It may be possible, but I'm worried that we don't yet understand reflection 
>> upon proxies well enough yet to expose the built-ins in that manner. It also 
>> it clear to me whether proxies are yet power enough to accomplish everything 
>> that is currently done with "host objects".
> We should do a stress-test on implementations and other specs that claim to 
> need more than what proxies now provide. I think we can ignore the legacy 
> stuff in WebIDL -- it can still be outlaw. What we want is a smaller ECMA-262 
> that biases for the future.

I think there's been a general move to kill off the various magic properties in 
webidl defined objects and replace them with getters/setters on the prototype.  
I think that the bulk of the DOM ends up relatively trivially becoming 
"regular" objects at that point.

Remaining problems are the DynamicNodeLists and related types (where things 
like the number and value of properties changes externally from JS) which seems 
like something that could be hidden behind a wall of "this is just a proxy", 
similar for the compat. layers like window.someElementName.

>From the PoV of JSC I suspect our biggest problem will actually be our API, 
>which essentially allows developers to override an arbitrary collection of 
>[[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our 
>api is that you can override [[HasProperty]] and [[GetProperty]] 
>independently, and have them be inconsistent :(

--Oliver

> 
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to