it's ambiguous with regular object creation.
Thanks. Dmitry.
On Tue, Aug 12, 2014 at 12:47 AM, Michael Wallner <m...@php.net> wrote:
> 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/
>> >
>> >
>> >
>> >
>> >
>>
>
