Closed sandersn closed 5 years ago
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.
Would welcome a PR that shows substantive perf improvement here (seems like the cognitive penalty is reasonably low), but either way this is speculative.
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.