We didn't keep pointers to functions in opcodes (however it possible in
some cases).
Instead we use cache_slots in op_array->run_time_cache array to keep
pointers to classes and functions.
Anyway, it must be quite easy to extend the patch.
Thanks. Dmitry.
On Mon, Aug 11, 2014 at 11:33 PM, Andrea Faulds <a...@ajf.me> wrote:
>
> On 11 Aug 2014, at 20:07, Dmitry Stogov <dmi...@zend.com> wrote:
>
> >
> > may be:
> >
> > $a = function strlen;
> >
> > or
> >
> > $a = function(stren);
> >
> > but these are not excellent as well :(
>
> I wanted to do the first, but it caused a shift/reduce conflict in the
> parser due to ambiguity with function () {}. The latter has been suggested
> also. Both might be possible with an AST, but I’m not really keen on
> either, they’re quite verbose.
>
> > I may implement this part if the RFC will be accepted.
> > Actually, most of the code may be just copy-pasted from
> > ZEND_INIT_STATIC_METHOD_CALL.
>
> Interesting, I’d certainly appreciate it. :) One thing to note is that the
> patch is currently implemented in the simplest way possible, wherein it
> just stores constant strings in the opcode. You could optimise it by
> binding ahead-of-time and passing the zend_function pointer itself, but I
> didn’t want to do that as it complicated things.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
