Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.166 as permitted sender)
Message-ID: <BLU436-SMTP1560BB6F59F470C82156EDE2070@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6EDF9BA8-B652-4F72-8F14-36D78F2327EE"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <CAF+90c_RTtHYrq__r=mosbaBXZCvLqXQjcQ0uJMFrAM2eXR6ww@mail.gmail.com>
Date: Tue, 1 Jul 2014 13:25:12 +0200
CC: Dmitry Stogov <dmitry@zend.com>,
 Andrea Faulds <ajf@ajf.me>,
 Xinchen Hui <xinchen.h@zend.com>,
 David Soria Parra <dsp@php.net>,
 Julien Pauli <jpauli@php.net>,
 PHP Internals <internals@lists.php.net>
References: <CA+9eiLtCyuMVN-CN_hnLCCij4nymUiKEa26K_S_qM1PN-g-4HA@mail.gmail.com> <FF875EF5-AC89-49DE-808A-DA734FBFD9BA@ajf.me> <CA+9eiLschCKWqXH2GE9C6VW3Hu9KXqyYMrQO08CoEM3VnvVMLQ@mail.gmail.com> <CAF+90c_RTtHYrq__r=mosbaBXZCvLqXQjcQ0uJMFrAM2eXR6ww@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] Wired constant expression syntax and bug
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_6EDF9BA8-B652-4F72-8F14-36D78F2327EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"

Am 1.7.2014 um 09:12 schrieb Nikita Popov <nikita.ppv@gmail.com>:
>=20
> >
> > >
> > > class FooBar {
> > >              const bar =3D ["bar" =3D> 3]["bar"];
> > > }
> > >
> > > It wasn't a part of RFC, it wasn't covered by tests, and it =
actually
> > > doesn't make a lot of sense. May be it's better to remove it?
> >
> > I disagree, it makes perfect sense:
> >
> > class FooBar {
> >    const FOO =3D 3;
> >    const BAR =3D [
> >        3 =3D> =91qux=92,
> >        4 =3D> =91bang=92,
> >        7 =3D> =91theta=92,
> >        9 =3D> =91epsilon=92
> >    ][FOO];
> > }
> >
> > ?: and ? only work when there are just two possibilities.
> >
>=20
> ?: may work with brackets, but I have to admit that it's less =
readable.
>=20
> class Foo {
>         const X =3D 2;
>         const Y =3D (Foo::X =3D=3D 0 ? 1 :
>                  (Foo::X =3D=3D 1 ? 2 :
>                  (Foo::X =3D=3D 2 ? 3 :
>                  (Foo::X =3D=3D 3 ? 4 :
>                  5))));
> }
>=20
> The situation is really inconsistent because we allow expressions on
> constant arrays but at the same time prohibit array usage.
>=20
> As we support the [..., ...][...] syntax in normal PHP code as well, I =
think it's reasonable to allow it here as well. Of course it isn't very =
practically useful, but there doesn't seem much point to explicitly =
disallowing it here.

That's exactly my point.

> Look into the following scripts:
>=20
>=20
> <?php
>  class Foo {
>    const BAR =3D [
>        3 =3D> =91qux=92,
>        4 =3D> =91bang=92,
>        7 =3D> =91theta=92,
>        9 =3D> =91epsilon=92
>    ][1];
> }
> var_dump(Foo::BAR); // works - prints 'bang'
> ?>
>=20
> <?php
>  class Foo {
>    const BAR =3D [
>        3 =3D> =91qux=92,
>        4 =3D> =91bang=92,
>        7 =3D> =91theta=92,
>        9 =3D> =91epsilon=92
>    ];
> }
> var_dump(Foo::BAR); // doesn't work - Fatal error: Arrays are not =
allowed
> in constants at run-time
> ?>
>=20
> <?php
>  class Foo {
>    const BAR =3D [
>        3 =3D> =91qux=92,
>        4 =3D> =91bang=92,
>        7 =3D> =91theta=92,
>        9 =3D> =91epsilon=92
>    ];
> }
> // This works again! We may declare array class constants if we don't =
use
> them?
> ?>
>=20
> Where is the logic?
>=20
> The reason here is probably that we cannot detect whether something =
will be an array or not until runtime constant updating. E.g. const BAR =
=3D FOO ? 1 : [1] or similar. However we might want to detect the case =
where an array is the root of the AST, as that is invalid for sure and =
the most common case.

Not sure if we should check that. That would be adding a new arbitrary =
restriction. Now the following works:

class Foo {
    const BAR =3D [
        3 =3D> =91qux=92,
        4 =3D> =91bang=92,
        7 =3D> =91theta=92,
        9 =3D> =91epsilon=92
   ];

    const BAZ =3D FOO[4];
}

var_dump(Foo::BAZ);

> Another small issue with the constant expressions I noticed is that =
our recursion detection doesn't properly work for constant ASTs. For =
example:
>=20
> <?php
> class A {
>     const FOO =3D [self::BAR];
>     const BAR =3D [self::FOO];
> }
> var_dump(A::FOO);
>=20
> This will result in a stack overflow instead of a fatal error about =
self-referencing constants.
>=20
> Nikita


I think that this is caused by some bugfix for opcache.

http://lxr.php.net/xref/PHP_5_6/Zend/zend_ast.c#255
That zval_copy_ctor call duplicates the AST to save it for opcache so =
that opcache can store it later.
But as that is called before the zend_ast_evaluate, the effects of =
MARK_CONSTANT_VISITED() won't affect the contents of the ast (and the =
zval with the constant) copied before=85

@Dmitry: Removing this call (and the dtoring in the ast destructor) will =
break opcache and fix this bug. How to fix both now? I don't immediately =
see a good fix here?

Bob=

--Apple-Mail=_6EDF9BA8-B652-4F72-8F14-36D78F2327EE--