Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any real pitfalls to the WeakMap approach? #105

Open
mmiller42 opened this issue Sep 23, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@mmiller42
Copy link

commented Sep 23, 2017

This might be an inappropriate place to ask this question, but I was looking at the example in the FAQ for using WeakMaps for encapsulation.

The potential pitfall shown seems to me to be easily averted, since there is no reason why makeGreeting would require access to private instance variables, and it would be easily mitigated with .call or .apply. Wouldn't this kind of situation easily be resolved by modifying greet(otherPerson) to do return privates.get(this).makeGreeting.call(this, otherPerson.name);? After all, the expected behavior in a realistic class of this kind is that makeGreeting would have access to the Person instance's public API, not its map of private members.

@bakkot

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2017

Yes, if you know the pitfall is there it can be avoided, with care. I would still consider it an issue, since most people are unlikely to notice. The only other major downsides I'm aware of are that it's fairly opaque as to intent, has unergonomic syntax (especially for chained property access), and is probably harder for engines to optimize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.