Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89896
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.195 as permitted sender)
MIME-Version: 1.0
Date: Sat, 26 Dec 2015 15:35:41 -0500
Message-ID: <CANmB6N8de7Hrs0VZOYoy9tSq9Jh7TvheBKX--qhLoc5Jf562wQ@mail.gmail.com>
To: francois@php.net
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11423c10f6286b0527d303bc
Subject: Re: [PHP-DEV] Make strict mode more strict?
From: ejrx7753@gmail.com (Elijah Johnson)

--001a11423c10f6286b0527d303bc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Fran=C3=83=C2=A7ois,

> > Hi Yasuo,

>>  Le 17/09/2015 00:10, Yasuo Ohgaki a =C3=83=C2=A9crit :

>>  Hi all,

>>

>>  Assigning different type to already initialized variable is a bug most

>>  likely. There may be cases that variable should have several types,

>>  e.g. return INT for success and FALSE for failure, but programmers can

>>  use different variable or return value directly or make BOOL/NULL

>>  exception.

> While I don't like the idea of 'auto-typing' a variable (assign it an
immutable type depending on the first assignment), the idea is quite
similar to one I proposed when we were discussing scalar type hinting :
the possibility to assign a type hint to every variable/property. In
order to be really usable, it requires compound types but that's a
detail because, anyway, we will need compound types.

> The problem is that, AFAIK, it implies a mechanism to attach an optional
> type hint to a zval, and check it each time a value is assigned. While
> this would be extremely powerful and could dramatically change the way

> PHP types are considered and handled, this is a huge and complex work,

> especially in terms of performance. IMO, this may be an idea for 8.0,

> not before. Anyway, I may be wrong, if you see a simpler way to
> implement your concept, I'm interested.

> Regards

> Fran=C3=83=C2=A7ois


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
source code where variables are assigned? I'm not yet discussing
performance, but only the aspect of adding the feature.

I'm not familiar enough with the code base, but I imagine that there
is one primary location where variables are assigned. Maybe a very
small finite number of other cases, such as list() and references. It
is possible that a c-function or extension could modify the variable
assigned to it, thereby adding a multitude of possible locations. Yet
I don't see that this is the case in any standard c implementations.
For example, php_array_walk taking a reference, should sort the array
in place and in any case not change the value-type.

As to adding an additional member to the zval struct, that could be
done with a simple bool value. The type of the object could be set
inside of the value struct. I believe that this is why Yasuo suggested
that the first set value should be chosen.

I also disagree with the idea of first-init value as being unclear. If
I am not mistaken, with an additional zend_uchar ie. IS_NULL_TYPEDEF =3D
"t" the value member union of zval could contain the identifier of
this class. Then update IS_NULL to return true also if "t". I am not
qualified to say if that is possible or do it, but it sounds like a
"finite" amount of work. I don't see a particularly large performance
impact on the language. We have an additional 1 byte per zval and some
type checks. Admittedly, the function needs to go a few levels deep in
the struct to get the type of an object (when already defined), but
performance-wise it should be minor. In the case of setting a null
value to an object/string or setting any value to a basic type, I
would imagine the impact to extremely small.

--001a11423c10f6286b0527d303bc--