On Fri, Jul 19, 2013 at 12:31 PM, Andreas Rossberg <rossb...@google.com>wrote:
> On 19 July 2013 18:17, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > > You have to be able to support Proxy exotic objects so, I don't see why > you won't use that exact mechanism for Symbol objects. > > Because they are different. There is no useful unified mechanism for > exotic objects, at least no efficient one. Every new form of exotic > object will be a new special case. As I said, the nice spec-level MOP > abstraction is largely irrelevant at the implementation level. > > I'm speaking from V8 experience here, but I would be surprised if the > situation is much different in other modern VMs. > > > In other words, use a self-hosted Proxy-based implementation for Symbol > objects. The MOP operations on Symbol exotic objects in all cases either > throw an exception or return some predetermined result such as undefined or > false. > > You can't use proxies for symbols -- they are special in parts of the > semantics (and that includes their wrappers, if we want them to be > special, too). I'm curious how symbols differ semantically from null-prototype, empty, frozen objects? I can't think of any substantive differences other the power to act as object keys (and some seemingly insignificant details like toString behavior). If that's truly the case, wouldn't it be a lot easier to just allow any null-prototype, empty, frozen object to have the object-key capability? For consistency Object.prototype.toString could even be specified to return something along the lines of [object Symbol] for values which fulfill this criteria (a breaking change, but only very slightly -- I can't imagine this affecting code in the wild). > And I doubt that you will be able to use them for other > exotic objects we might come up with (e.g. value objects would have > special equality behaviour that proxies can't simulate). > > Even if you could, I highly doubt that proxy performance will ever be > up for the task, at least not for an implementation cost that isn't > much higher than the special casing. > > /Andreas > _______________________________________________ > 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
