Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75392
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.180 as permitted sender)
Message-ID: <53C28081.10005@gmail.com>
Date: Sun, 13 Jul 2014 14:50:09 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ajf@ajf.me
CC: internals@lists.php.net
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
In-Reply-To: <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: jocelyn.fournier@gmail.com (Jocelyn Fournier)

Hi,

Would it possible to control the implicit casting through a PHP variable 
? (or perhaps modify E_STRICT to display a warning if this kind of 
implicit cast is done ?)
I mean specifying explicitly a type is often useful to make sure the 
proper type is passed to the function, and there's no bug in the calling 
func.

e.g. safety check like

function foo($bar) {
    if (!is_int($bar)) {
       throw new Exception('Invalid parameter type');
    }
}

will not be "equivalent" to

function foo(int $bar) {

}

and there will be no way to have an equivalent behaviour once "type 
hinting" is used !


Thanks,
   Jocelyn


Le 13/07/2014 14:09, Nikita Popov a écrit :
> On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds <ajf@ajf.me> wrote:
>
>> Good evening,
>>
>> PHP’s type hinting system is rather incomplete as it does not support
>> scalars, only arrays, callables and objects. In 2012, Anthony Ferrara
>> created an RFC which proposed type hinting for scalar types (int, float,
>> bool, string and resource) with casting, with behaviour nearly the same as
>> that of zend_parse_parameters. Sadly, he later left PHP internals and
>> withdrew his RFCs.
>>
>> Since I am very much in favour of scalar type hints, I’ve updated the
>> patch to master and made some minor improvements, and I am re-opening the
>> RFC with the intent to try and get it into PHP 5.7. The patch is mostly
>> there. It needs some more tests and there are some edge cases I need to
>> deal with, but it otherwise works, and I expect I can finish fixing it up
>> very soon.
>>
>> The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast
>>
>> A pull request is here: https://github.com/php/php-src/pull/717
>>
>> I’m hoping I can get this into PHP 5.7. I think scalar type hinting would
>> be a valuable addition to PHP’s existing type hinting system.
>>
>> Thanks!
>>
>
> I think the approach described in this proposal is the best way to
> implement scalar typehinting, as it allows typical loosely-typed usage
> patterns, while still providing type guarantees within the function.
>
> I haven't yet closely reviewed the details of what is and isn't allowed,
> but one things I would strongly recommend against is introducing any
> "accept but throw a notice" cases. Either a value is allowed or it isn't.
> "12foo" to an int/float argument should throw a recoverable fatal error,
> like everything else. (I'd change that in zpp as well, but that's a
> different discussion).
>
> The question of passing floats like 12.5 to an int param is somewhat
> tricky. One could argue that it's possible to end up with floats like
> 12.0000000001, which are nearly integers but not quite there, and a user
> might expect them to behave the same as the integer 12. On the other hand
> one can also argue that it's easy to end up with the inverse, namely
> 11.999999999999. In this case the end user might also expect it to be
> treated as integer 12, however an integer cast will truncate it to 11.
>
> The truncation behavior of the float to int cast is why I tend towards the
> behavior the RFC currently proposes (forbid non-integral floats): It is
> rather unlikely that truncation is what was intended, as such an explicit
> rounding call is necessary anyways.
>
> Nikita
>