> 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 }
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
