> I'd say you've identified the common pattern, but that pattern itself is
a bad use case, and the use of private symbols as you have defined them
doesn't do anything to correct the technical issue.

I think there’s been a misunderstanding. Everybody agrees that that’s a bad
pattern. It’s not what the point of private symbols would be. It’s not a
target use case.

> Since you cannot stick new properties onto a non-extensible object, even
private symbols won't solve the problem with your use case.

That appending private symbols to external objects which are frozen
wouldn’t work doesn’t matter precisely because it’s not a target use case.
That it doesn’t work reliably might even be considered a positive, since it
discourages something we all seem to agree is not good practice.

It’s also not related to private symbols; this is already how properties
work, regardless of what kind of key they have.

> The difference here is that in your use cases, library A is "sneakily"
storing information on object B.

What use case are you referring to here? I can’t find any example in the
previous posts that matches these descriptions. As Isiah said, “all of the
examples here I've presented are for scenarios where the state is related
to the factory that created the objects.” The same is true of my examples.
Everybody’s on the same page regarding not wanting to add properties to
objects their own libraries do not create.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180731/2255a08f/attachment.html>

> I'd say you've identified the common pattern, but that pattern itself is a bad use case, and the use of private symbols as you have defined them doesn't do anything to correct the technical issue.

I think there’s been a misunderstanding. Everybody agrees that that’s a bad
pattern. It’s not what the point of private symbols would be. It’s not a
target use case.

> Since you cannot stick new properties onto a non-extensible object, even private symbols won't solve the problem with your use case.

That appending private symbols to external objects which are frozen
wouldn’t work doesn’t matter precisely because it’s not a target use case.
That it doesn’t work reliably might even be considered a positive, since it
discourages something we all seem to agree is not good practice.

It’s also not related to private symbols; this is already how properties
work, regardless of what kind of key they have.

> The difference here is that in your use cases, library A is "sneakily" storing information on object B.

What use case are you referring to here? I can’t find any example in the
previous posts that matches these descriptions. As Isiah said, “all of the
examples here I've presented are for scenarios where the state is related
to the factory that created the objects.” The same is true of my examples.
Everybody’s on the same page regarding not wanting to add properties to
objects their own libraries do not create.