Hi Eliah,
Thank you Eliah. I was planning to discuss this next year.
Following paragraph is for others. Making sure prevent confusions.
I've implemented session.use_strict_mode, but this discussion is for
"strict type mode".
I was proposing type check for variable conversions.
e.g. Raise error/exception for "string" to "int" conversion.
On Sun, Dec 27, 2015 at 5:35 AM, Elijah Johnson <ejrx7...@gmail.com> wrote:
> Hi François,
>
>> > Hi Yasuo,
>
>>> Le 17/09/2015 00:10, Yasuo Ohgaki a écrit :
>
>>> 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çois
>
>
> 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.
Performance will be increased overall because unnecessary type conversions
will be removed. e.g. $_GET/$_POST variables are "string", but numeric IDs
in these array will be converted to "int" over and over.
$something = get_something_by_int_id($_GET['id']); // "string"
$_GET['id'] is converted to "int" with type hint
All inputs must be validated anyway, so initial type conversion is inevitable
overhead.
I'm expecting overall performance increase, but I cannot be sure w/o
benchmarks. There are many cases that treating "numeric string"
as "string" is the fastest. e.g. Many native database's API assumes
"string" data for them and returns "string" data.
> 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'm sorry. I cannot be sure what part you're discussing. Your reply
is new thread.
My proposal does not require new member in zval structure, but
requires error/exception to automatic variable type conversions.
(NULL type could be special case like SQL. This should be discussed
fully.)
>
> 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 =
> "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.
>
IIRC, my proposal had 2 parts
1. Introduce type affinity to $_GET/$_POST/$_COOKIE and
affinity functions for external data like SQL, JSON, XML, etc.
(Similar to SQLite's type affinity. SQLite stores any value to
columns, but convert integer like string to native int/long.)
https://wiki.php.net/rfc/introduce-type-affinity
2. Introduce error/exception for type conversions.
No RFC yet.
Bool type handling is subject to discuss. The way INI converts value to
bool type may be used. Or let programmers handle appropriate conversions
as a part of input validation. e.g.
$_GET['bool'] = $_GET['bool'] === 't' ? TRUE : FALSE; // Treat 't' as
TRUE, otherwise FALSE.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
