Re: Idea for better function callbacks (another syntactic sugar)

From: Date: Sun, 28 Oct 2018 02:54:04 +0000
Subject: Re: Idea for better function callbacks (another syntactic sugar)
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-103407@lists.php.net to get a copy of this message
On Fri, Oct 26, 2018 at 3:09 PM Kalle Sommer Nielsen <kalle@php.net> wrote: > > Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison <levim@php.net>: > > 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).

« previous php.internals (#103407) next »