On Jul 19, 2013, at 11:37 AM, Andreas Rossberg wrote: > On 19 July 2013 18:52, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: >> On Jul 19, 2013, at 9:31 AM, Andreas Rossberg wrote: >>> 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). 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). >> >> Note that I was talking about the symbols as exotic objects path, not the >> symbols as new primitive type path so there would be no wrappers. In what >> way are the object semantics of exotic symbol objects special such that >> couldn't be represented via a Proxy handler? >> >> The special behavior of symbols appears, to me to be all ready of operations >> that are not part of the MOP. Hashing for property lookup, comparison during >> lookup, etc. I still don't see why the Proxy MOP dispatch mechanism wouldn't >> be perfectly adequate for their generally pointless application to symbols. > > That would at least require some way of distinguishing ordinary > proxies from those internal symbol proxies, so that they can cheaply > be recognised as symbols. Alas, a separate proxy type, or extra > internal info you need to store in every proxy.
Whether proxies are used or not, you still need to do make that distinction. An identify test on the proxy handler or target reference might be one cheap way to identify them. There are undoubtably many other possibilities. > > At the same time, proxies already come with a space overhead that you > don't want to pay for symbols. > > No, I think that proxies would be total overkill here, and yet not > even sufficient. This little subthread started with with you wanting to minimize the complex of another implementation level exotic object type. This is one way to do it. There are space and time trade-offs to be made but it definitely is not an absurd approach to consider. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
