Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender)
Message-ID: <53C45D78.1020105@sugarcrm.com>
Date: Mon, 14 Jul 2014 15:45:12 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, PHP internals <internals@lists.php.net>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
In-Reply-To: <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> One of the issues with the RFC as it stands is how to handle bool
> casting. While int, float and string only allow lossless casting
> (with the exception of objects, but we can’t really do anything about
> that), bool’s behaviour at the moment is quite different. I don’t
> think it makes sense so I won’t discuss the current behaviour, only
> possible new ones.

Most cases where bool is used is meant as "yes or no" parameter. In
those cases, getting non-boolean there may mean one of the following:

1. A complete error, passing wrong parameter by mistake.
2. Passing something that is meant to represent preference, but is not
an actual boolean - i.e. null, empty string, string '1', object, etc.

Traditionally, many languages - including PHP - were lenient in
accepting non-boolean objects in boolean contexts - so you can say
if($obj) and mean "true if $obj is a real object, false if $obj is
something like false or null" instead of if((bool)$obj). In such
context, it is clear what the intent is, and the possibility of error is
very low.

However, when passing parameters the other option - one that implies the
error was passing a different parameter - is an option. The question is
how potential catching such error - noting that it would be caught only
if the other parameter is not boolean and the value is not boolean and
we do not use (bool) - is important over other considerations.

So here I would say we should take a consistent approach. By this I mean
- if we say scalar typing is coercive - i.e. if you say foo(bar $x), it
means $x should be coerced into type "bar" or rejected if it does not
make sense - then we should follow the general rules of boolean
conversion and say any object can be turned into boolean, by the same
rules as if() would take them.
If, on the contrary, we take it as $x must be of type bar, or we reject
it - then we should not accept anything but boolean. This however will
lead us into strict typing, the concept which I personally oppose in
this context, but would not elaborate further here since it was already
done many times.

In any case, I think it is important to realize this decision is not
arbitrary, but connected to the rest of things - if you choose strict,
it makes no sense to be strict only in one place. If you choose
coercive, type casting rules should be consistent for all cases, not
special for every syntax.

> work, anything you got from $_GET (e.g. ?foobar=1). However, this is
> unlikely to catch bugs in code, because literally any PHP value would
> work. For that reason, I’m not sure this is the way forward.

Making it strict would not help here - people would just be trained to
write (bool) everywhere, and thus the same bugs would be masked the same
way, only in much uglier code.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/