Repository navigation
Symbol tables should keep internal properties separate #16868
Description
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.
Activity
ahejlsberg commentedon Jul 3, 2017
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.
RyanCavanaugh commentedon Sep 16, 2019
Would welcome a PR that shows substantive perf improvement here (seems like the cognitive penalty is reasonably low), but either way this is speculative.