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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
