Comments on Sept Meeting Notes

Kevin Smith zenparsing at
Fri Sep 27 12:37:33 PDT 2013

> 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.

> 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?

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.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list