Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80124
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.137.24 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAEZPtU79=VX1Scm6vVn-9iuHD=qqRoPMrsR4Ymqd9=QQeQbRCg@mail.gmail.com> <360F9366-07C2-4C7A-AC3C-D482AFDD9838@ajf.me><CAOjCV8wshLQJYqRPXS7wEodwhkMK-_W0qvxzNMe1F=SYe8svmA@mail.gmail.com>
To: ajf@ajf.me, sbj.ml.read@gmail.com
Cc: pierre.php@gmail.com, internals@lists.php.net
Message-ID: <20150103200059.029362605AB@dd15934.kasserver.com>
Date: Sat,  3 Jan 2015 21:00:58 +0100 (CET)
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: mails@thomasbley.de ("Thomas Bley")

Here is what I run on my ubuntu 14.04 for compiling & testing:

apt-get install build-essential re2c bison
git clone -b master https://github.com/php/php-src.git
cd php-src
curl https://github.com/php/php-src/pull/972.patch | git am
./buildconf
./configure
make
sapi/cli/php /tmp/test.php

test.php is my testing script.

Regards
Thomas

Sebastian B.-Hagensen wrote on 03.01.2015 20:46:

>>> - on-numeric strings not accepted. Numeric strings with trailing
>>> characters are accepted, but produce a notice.
>>>
>>> I would rather not allow fancy conversions here. Any trailing non
>>> white spaces characters should not be allowed. I know it is not what
>>> PHP does now in some cases but this is really a fuzzy area and never
>>> really matched any actual needs or usages.
>>
>> Yeah, I don’t like this behaviour much. I want to avoid inconsistency with
>> the behaviour of extension functions (i.e. zend_parse_parameters) where
>> possible, though. Since this has come up so much, I should probably make an
>> RFC to change this aspect of ZPP’s behaviour.
> 
> That RFC should probably be voted on before this RFC proceeds into voting.
> 
> After skimming through the RFC I'm unsure what the following code would
> produce:
> 
> function test(int $a, int $b) {}
> 
> test("10.4", 10.6);
> 
> If a warning/notice is raised, fine. If it will just result in $a ===
> (int)10 && $b ===(int)10 :
> 
> I agree that consistency is a sound reason for this behavior. However
> type annotations (or whatever they will be called) should not only
> ensure that a parameter has a certain type but that no data was lost
> during the conversion. It is reasonable (assuming the target type can
> handle the value) and fine to convert an integer into a float,  a
> float/integer to a string or any string that would satisfy is_numeric
> into a float (or if no data was lost an integer) and hide it from the
> developer (after all, that is was php is about). If a conversion might
> result in data or precision loss the developer should be notified with
> a hard failure. (E_RECOV, E_WARNING, I can still chose to ignore them
> using error handlers or error_reporting settings).
> 
> Allowing data (I would also consider (string)'12a' => int(12) data
> loss) or precision loss while converting a typed parameter would
> reduce the usability of the whole addition.
> 
> If I'm in a situation where data loss is acceptable I could just leave
> the annotation away and cast as I would've always done or not cast and
> trust on php to do whatever is required.
> However caring about data loss in these specific occasions( including
> the string -> int example above) would forbid me to use type
> annotations. As I would have no way of knowing and bailing out if the
> original value was altered before it was accessible by my code.
> 
> If type annotations wouldn't go beyond the safety that php currently
> provides by converting in specific contexts and casting what is the
> benefit in adding them?
> 
> However, while I see issues with the RFC (that might be related to a
> misunderstanding on my side) I like the general direction.
> 
> 
>>> I am also not a fan of errors, exception, at least for methods, make
>>> much more sense. I know it is relatively easy to handle errors as
>>> exception but still, let do it right now.
>>
>> That’s be inconsistent with our other type hints. To get this changed, I
>> think we’ll just have to wait for Nikita’s Exceptions in the Engine for
>> PHP 7 RFC.
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>