How about 'new Function()'?
Might be a WTF that it creates an instance of Closure, though.
On 11 Aug 2014 22:32, "Dmitry Stogov" <dmi...@zend.com> wrote:
> 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/
> >
> >
> >
> >
> >
>
