Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89909
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
Sender: tomac120@gmail.com
In-Reply-To: <56811E49.1040106@php.net>
References: <CANmB6N8de7Hrs0VZOYoy9tSq9Jh7TvheBKX--qhLoc5Jf562wQ@mail.gmail.com>
	<56811E49.1040106@php.net>
Date: Mon, 28 Dec 2015 10:03:50 -0500
Message-ID: <CAGTDVF5RAxkExV2WDfBdeNb5x+5+aQDYkSAn+2wRkbxKyYVoBw@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=047d7bd6a9d6d731460527f69c27
Subject: Re: [PHP-DEV] Make strict mode more strict?
From: ejrx7753@gmail.com (Elijah Johnson)

--047d7bd6a9d6d731460527f69c27
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks,

On Mon, Dec 28, 2015 at 6:34 AM, Fran=C3=A7ois Laupretre <francois@php.net>
wrote:

> Hi,
>
> Le 26/12/2015 21:35, Elijah Johnson a =C3=A9crit :
>
>> Can you explain your statement that this would be a huge and complex
>> work? You must mean that there would be multiple places in the php sourc=
e
>> code where variables are assigned? I'm not yet discussing performance, b=
ut
>> only the aspect of adding the feature.
>>
>
> There may other options I don't know but, AFAIK, this implies adding an
> optional type hint at the zval level. This type hint should be verified a=
t
> least before each conversion.  Copy-on-write is an other issue, as it is
> currently not compatible with zval type hints. Seeing only variables with
> well-defined names, and focusing on arrays, only scratches the surface.
> Everything happens at the zval level. So, IMO, attaching type hints to
> variables and properties is a huge and complex work.
>
> Regards
>
> Fran=C3=A7ois
>

I think I see what you are saying. Copy on write takes a reference to the
entire z-val in two local variables, so a type-hint at the z-val level
would be shared.

This returns us to the insight of the original mailer who suggested that an
object or array variable should be typed by its first-assigned object. This
would simply need to be a global mode - stack-mode-legacy,
stack-mode-static-object-types, and stack-mode-super-strict for those who
want basic types also.

I'm not saying that this is ideal, just that we need to compromise a bit to
accommodate our existing code base and performance issues.

The proposal for an additional z-val which stores the class name in the
zval.value member and is counted as null could accommodate the case where
the user wants to assign the type before he has an object.

I think this is the best option. Another theory I had was to store the
types at the context level in some kind of array, but its really too much.

The idea just now proposed of 3 global modes will eliminate the issue of
storing at the z-val level. The mode "stack-mode-static-object-types" is
even already compatible with every line of code that I have properly
written in PHP.

--047d7bd6a9d6d731460527f69c27--