On Wed, Jul 31, 2013 at 6:21 PM, Dean Landolt <d...@deanlandolt.com> wrote:
> That leaves default non-enumerability. Consider the fact that object > literal methods are enumerable. Why should choosing a "unique name" as > opposed to an identifier for a method have any bearing on enumerability? > > > I was pointing out the very real hazard that exists in code which wouldn't > be considered objectively bad. To be explicit, I'm claiming that for/in > over object keys can be the Right Thing in cases where you want all > enumerable keys up through the prototype. If unique symbols aren't > enumerable *and* the platform demands any of them on Object.prototype > this will introduce subtle run-time breakages at least as badly as "null" > typeof. Even if es6 avoids them on Object.prototype who's to say they won't > be needed in later versions? This will bite eventually. > I agree that this is something we should care about. Would implicitly treating identifiers that have the right format as symbols solve this? I.e., instead of having to explicitly create a unique symbol, just using a string of the right ugly format makes the engine treat fields with that identifier as the key as non-enumerable.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
