On Fri, Oct 26, 2018 at 3:09 PM Kalle Sommer Nielsen <[email protected]> wrote: > > Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison <[email protected]>: > > In my opinion "ideal" here is that our symbol tables are merged, so > > referring to "trim" in any context will resolve to at most one symbol, > > *and* that we also have a short-closure syntax for times when there > > isn't a *perfect* function to use. > > > > In the next version of PHP I would really like to see some warnings > > for when symbol names get re-used so that in the future we can merge > > them with less of a BC break. > > I like that idea a lot tbh, but I do worry a lot about the lookup time > if we end up with a gigantic hashtable to hold all the symbols and the > implications it has. In most contexts we know (based on the syntax) > what we are looking for, however as it currently stands then it would > not be clear wether to look for the constant "trim" or the procedural > function "trim" in the example given, and if thats all the same, I can > see that many things not utilizing this could be slower for no good > reason (at least in my honest opinion). However I don't know if there > is something sneaky we can do here.
The symbols will probably kept in separate tables even after the change, with the order being determined by context. I don't worry about this performance hit, because callbacks are already so slow I don't think an extra hash lookup or two in the worst case will make this worse. And in some cases string callables have overhead at runtime because they have to search for "::", although I'm not up-to-date on where exactly we do this (it was looked into at one point). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
