Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.169 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <53EC8D31.10807@gmail.com>
References: <5DCAA9AE-CC08-48BA-A0D4-78818BD5D656@gmail.com>
 <CAMUwpuQqZDGd0yOg=B8VYM6XfS8ztz9OvHx2QQss1Teba1-PAg@mail.gmail.com> <53EC8D31.10807@gmail.com>
Date: Thu, 14 Aug 2014 14:21:04 +0200
Message-ID: <CAMUwpuTjjpAscbZQrhgbTGjFtSjcpcSTN+eRxo68hab-nG=utg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Evaluation of constructor arguments if there's no constructor
From: jpauli@php.net (Julien Pauli)

On Thu, Aug 14, 2014 at 12:19 PM, Rowan Collins <rowan.collins@gmail.com> w=
rote:
> Julien Pauli wrote (on 14/08/2014):
>
>> On Thu, Aug 14, 2014 at 8:26 AM, Tjerk Meesters
>> <tjerk.meesters@gmail.com> wrote:
>>>
>>> Hi internals,
>>>
>>> I was sifting through the bucket o=E2=80=99 bugs and found these two re=
lated
>>> issues:
>>> https://bugs.php.net/bug.php?id=3D67829
>>> https://bugs.php.net/bug.php?id=3D54162 (closed)
>>>
>>> They concern the behaviour of the engine when a class defines no
>>> constructor or if the class to be instantiated doesn=E2=80=99t exist, w=
hich can be
>>> seen here: http://3v4l.org/jOQY0
>>>
>>> This is obviously a design decision, but doesn=E2=80=99t seem to have a=
 mention
>>> in the documentation nor the spec (I couldn=E2=80=99t find it under the=
 =E2=80=98new=E2=80=99
>>> operator).
>>>
>>> I can add a paragraph in the documentation for it; the question is
>>> whether it should also be added to the spec, seeing how HHVM and PHP be=
have
>>> differently in this respect? It could be added as implementation depend=
ent
>>> behaviour I suppose?
>>
>> This is a known behavior which is part of the VM.
>> It is designed at http://lxr.php.net/xref/PHP_5_5/Zend/zend_vm_def.h#338=
3
>>
>> I guess its an optimisation that prevents the compiler from compiling
>> a ZEND_DO_FCALL for constructors, which optimizes a bit the VM path
>> for object construction.
>> Dmitry should have more informations.
>>
>> I'm +1 for a documentation or spec mention.
>>
>>
>> Julien.Pauli
>>
>
> When it came up on StackOverflow chat, it was cheekily dubbed "Rasmus
> evaluation", because nobody could find any theory matching that particula=
r
> optimisation: https://chat.stackoverflow.com/transcript/11/2013/9/28/14-1=
7
>
> I'm still not entirely sure it's a good idea, and can't imagine how anyon=
e
> would rely on it (if you have a look at that trasnscript, you'll find som=
e
> fun attempts at finding an esoteric use). Is it really that big an
> optimisation that it's worth such surprising behaviour?

Well, in fact the INIT_FCALL and DO_FCALL are generated by the
compiler, but the executor optimizes by jumping over all the opline of
the constructor if this latter is not declared at compile time.
As a side effect, if the argument is to be IS_VAR or IS_CV , it won't
be interpreted, thus this behavior.

It may be possible to interpret the argument, but I think it will need
new OPCodes, like ZEND_NEW_WITH_CTOR and ZEND_NEW_WITHOUT_CTOR , and a
compiler patch to support those.
This may be thought for PHP7, and I think will benefit from the
ast-compiler RFC if its voted.

Dmitry or Nikita could bring more information about this as well.

Julien.Pauli