You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: