Skip to content

Symbol tables should keep internal properties separate #16868

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

Closed
sandersn opened this issue Jun 30, 2017 · 2 comments
Closed

Symbol tables should keep internal properties separate #16868

sandersn opened this issue Jun 30, 2017 · 2 comments
Labels
Unactionable There isn't something we can do with this issue

Comments

@sandersn
Copy link
Member

Right now symbol tables store things like __call and __construct alongside user-provided symbols. This forces us to mangle/unmangle symbols that start with two underscores. Instead, symbol tables should keep a map of user-provided symbols as before, but also provide optional properties for internals like __call et al.

When the symbol() type becomes available, the symbol table should also include an "dynamic names" map in addition to the "user-provided names" map.

@ahejlsberg
Copy link
Member

In principle I agree, but the challenge here is to make a new representation not consume more memory. We allocate an awful lot of symbol tables (many of them very small), and we wouldn't want to double that number. The advantage of the current representation is that we can put it all in a single map.

@mhegazy mhegazy added the Needs Investigation This issue needs a team member to investigate its status. label Aug 29, 2017
@RyanCavanaugh RyanCavanaugh added Unactionable There isn't something we can do with this issue and removed Needs Investigation This issue needs a team member to investigate its status. labels Sep 16, 2019
@RyanCavanaugh
Copy link
Member

Would welcome a PR that shows substantive perf improvement here (seems like the cognitive penalty is reasonably low), but either way this is speculative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Unactionable There isn't something we can do with this issue
Projects
None yet
Development

No branches or pull requests

4 participants