Comments on Sept Meeting Notes

Yehuda Katz wycats at
Fri Sep 27 13:15:35 PDT 2013

On Fri, Sep 27, 2013 at 12:37 PM, Kevin Smith <zenparsing at> wrote:

> Whether you personally use it, for-in is a reality. Introspection of
>> objects happens, so if you ship a library that's putting meta-level
>> properties into objects it needs to make them non-enumerable to be robust
>> in the face of client code that uses for-in but isn't prepared to
>> understand the meta properties.
> Is there a concrete example which shows how enumerability of meta-level
> properties would present a problem for such code?  That might be convincing.

Here are some examples:

   - Checking to see whether an object is empty. In Ember we do this, for
   example, to keep track of whether the list of changes to a model has become
   empty (and therefore to mark the object as clean). That's just one example.
   - Iterating over an object to print out a version for inspection.
   Meta-level properties (1) shouldn't be printed in such casual inspections,
   and (2) often contain recursive references that can cause infinite loops.
   Ember hit this issue with JSDump.
   - Iterating over an object in unit testing frameworks to compare for
   "deep equality". For example, you may want to compare whether some object
   is "deep equal" to { foo: bar }, but don't want to include Ember's
   meta-level properties that track observability.

In Ember, we mark our two meta-level properties as non-enumerable after
hitting some of these issues.

It's probably possible to work around these issues carefully, but
non-enumerability eliminated the entire class of problems triggered by
interactions with third-party libraries.

>> Once again, read the above links. You aren't distinguishing between the
>> ergonomics of the *provider* of a symbol and the *consumer* of a symbol,
>> and it's the latter case that matters. The ergonomics are better for the
>> consumer of a symbol than that of an obfuscated string, especially when
>> working with developer tools or code that manipulates the key and ends up
>> surfacing the obfuscated string.
> In re-reading the above links, you seem to be fighting a strawman.  I
> don't propose using GUIDs at all.  That would be awful.  I propose using
> "@"-prefixed strings, whose ergonomics is clearly superior to the
> symbol-based solution.
> Yes, prefixed strings don't give you a collision-free guarantee.  Do we
> need that for meta hooks?  Why?

Once we start using @foo in ES, libraries will adopt the pattern (just as
they did for dunder properties). Then we'll hit the same issue in ES7 when
we want to add a new property. I've said this a few times in this thread.

> Why would you even need to worry about a user-created object
> *accidentally* using a well-known "@"-prefixed string?  Remember, I
> proposed that hooks are always functions, so the "JSON.parse"
> counter-argument doesn't apply.

The problem is code written in the ES6 era interacting with well-known
"@"-prefixed Strings created in the ES7+ era (and the same for ES7, ES8+,

The "find a sequence of characters that is both ergonomic and not heavily
in use" solution only works one time. If it's indeed ergonomic, it will be
used in userland and then it will fail the "not heavily in use" requirement
in the future.

> { Kevin }
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list