> -----Ursprüngliche Nachricht-----
> Von: Zeev Suraski [mailto:z...@zend.com]
> Gesendet: Mittwoch, 18. Februar 2015 14:03
> An: Robert Stoll
> Cc: Sara Golemon; PHP internals
> Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
>
> > -----Original Message-----
> > From: Robert Stoll [mailto:p...@tutteli.ch]
> > Sent: Wednesday, February 18, 2015 1:14 PM
> > To: 'Zeev Suraski'; 'Nikita Popov'; 'Rasmus Lerdorf'
> > Cc: 'Sara Golemon'; 'PHP internals'
> > Subject: AW: [PHP-DEV] Scalar Type Hints v0.4
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Zeev Suraski [mailto:z...@zend.com]
> > > Gesendet: Mittwoch, 18. Februar 2015 08:00
> > > An: Nikita Popov; Rasmus Lerdorf
> > > Cc: Sara Golemon; PHP internals
> > > Betreff: RE: [PHP-DEV] Scalar Type Hints v0.4
> > >
> > > I am wondering what the point is indeed with preventing "123" to 123.
> > > So far, all the concrete use cases people brought up had to do with
> > > "Apple" or
> > > "100 dogs", but nobody ever seems to be able to explain why
> > > converting
> > "123"
> > > to 123 is likely to be a problem real world. Is it really just
> > > static analyzers?
> > >
> >
> > Strict mode is useful in the sense that it prevents unnecessary
> > implicit conversions (which are costly) and it improves readability.
> > Following an example:
> >
> > function foo(string $x, int $y){
> > bar(1);
> > return strstr($x,"hello", $y);
> > }
> >
> > function bar(float $a){}
> >
> > After adding the implicit conversions the code would look as follows:
> >
> > function foo(string $x, int $y){
> > bar((float) 1);
> > return strstr($x, "hello", (bool) $y); }
> >
> > function bar(float $a){}
> >
> > In strict mode the original code would not be valid (rightly so IMO).
> > Just from reading the original code I would suspect that strstr
> > expects some kind of an offset (hence the int), therefore strict mode
> > probably revealed a bug.
>
> There are two things I'm not so clear about in what you're saying.
> It seems that the 2nd sample adds explicit casts and not implicit casts.
[Robert Stoll]
Sorry, I was probably not clear enough. I just tried to illustrate what
internally happens, how the code could look like after the implicit conversions
were added. I am aware of that this was oversimplified since the implicit
conversions do not correspond to the explicit ones (which is inconsistent IMO
but this is another story).
The point I tried to make is, that the following code is not very readable (is
misleading) and that the lack of strictness results in unnecessary implicit
conversions:
function foo(string $x, int $y){
bar(1);
return strstr($x,"hello", $y);
}
- The implicit conversion of 1 to float is unnecessary (and thus an extra cost)
- the user should have written 1.0
- The implicit conversion from $y to bool hides that strstr expects a bool as
third argument and hence hides a potential bug
Two use cases where strict mode would be beneficial. However, the first case is
not so dramatic. PHP is not a high performance language and thus it is
perfectly fine IMO to have unnecessary implicit conversions. Yet, the latter
point is a use case where I would like to have strict mode. Same for the
following:
$a = strpos("hello","h");
if($a){}
if the condition of the if statement would be strict I could not have
introduced this very common bug.
> Explicit casts are actually use a much more aggressive ruleset than even the
> ruleset in the v0.3 RFC, in the sense that they'd
> happily convert "Apple"
> into (float) 0.0, if you do an explicit (float) cast. They (almost) can't
> fail.
[Robert Stoll]
Aye, a pity that safe casting functions where rejected:
https://wiki.php.net/rfc/safe_cast
But maybe this discussion revive the RFC
> Secondly, I think there aren't any common situations where strict typing (in
> the form of zval.type comparison) would be
> any less costly than weak typing.
> The difference is really between failure (abort in case there's a type
> mismatch in strict) and success (convert to the
> requested type). The conversion that may happen in the weak scenario is no
> costlier than an explicit cast, probably a tiny
> bit less actually.
>
[Robert Stoll]
I was not clear enough, I merely meant unnecessary casts are costly
> Again, in my opinion pushing users towards explicit casts - which have much
> more lax rules than the ones proposed in v0.3,
> let alone the ones we're currently considering, will defeat the purpose and
> actually make finding bugs harder.
[Robert Stoll]
I share this view, as I stated below, strict mode only makes sense with safer
casts IMO. I think it would be clever to agree on the way "safe casts" should
work, expose them to userland and if we should not get scalar type hints into
PHP 7.0 then we have at least safe cast functions which allow almost the same
but with a bit more code.
>
> > And if not, then one can add the conversion manually. However, this is
> > not as trivial as it sounds. Personally I think it would only make
> > sense to have strict mode in PHP if the user had more strict
> > conversion functions at hand. What is the benefit of the following? if
> > the conversion to int is as sloppy as today then one does not gain
> > anything from the strict mode IMO:
> >
> > function foo(int $x){}
> > foo( (int)$_GET["bla"]);
>
> I agree, but changing the rules of explicit casts is a *huge* change and BC
> break. If we do implement the single-mode,
> stricter-than-pure-weak and weaker-than-pure-strict ruleset, we could
> introduce a new set of conversion functions, along
> the lines of safe_int(), that would follow the same rules as the
> corresponding type hints (i.e. accept (int) 32, (string) "32",
> but not (float) 32.7, or (string) "32 dogs").
>
> Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
