On Jul 17, 2013, at 7:46 AM, Andreas Rossberg wrote:
> On 16 July 2013 19:33, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote:
> ...
>> Because MOP operations on symbols are never important, so that
>> representation should be fine from the object perspective. For actual
>> property access, its only the identify of the symbol that matters.
>
> That's not true for implementations. For example, you need hash values
> for symbols.
>
>
>> I sense, that you issue may be that you have implementation issues relating
>> to property looking/caching that perhaps relates to your representation of
>> string primitive values. Is your issue that a symbol primitive typed
>> modeled after strings will be easer to fit into your implementation? If so,
>> it isn't clear that this ease of retrofit consideration carries over to
>> other implementations.
>
> That's certainly true as well, e.g. I want to access hashes uniformly
> (and I believe that other implementations will want to follow a
> similar strategy to avoid the cost of extra case distinctions). But
> it's not the only point, see above.
>
You also need hash values for objects to implement Maps/Sets, etc.
Representationally, I would expect most implementations to have a common base
representation for all heap allocated entities including strings and objects.
But your design may be different.
Regardless, I think it is quite possible to exhibit property lookup designs
where object-baeed keys make absolutely no complexity/performance difference.
(its a different language, but high perf Smalltalk engines come to mind). So it
is probably a wash. Some existing implementations may have to do more and some
less to support symbols as objects. That's generally the case for most new
engine-level ES features.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
