On Jan 30, 2012, at 11:17 AM, Oliver Hunt wrote: > > 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.
The Object Model Reformation proposal http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation offers another approach for accommodating things like HTML node lists. > > 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 :( Some of this factoring appears to have been done simply for economy of expression. I'm all for cleaning up the internal methods to eliminate such unneeded flexibility and to bring them inline with Proxy handlers. Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
