Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76137
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <53D2AE01.8020806@sugarcrm.com>
Date: Fri, 25 Jul 2014 20:29:11 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <253874AE-F389-4357-8FBD-7135C02BD797@ajf.me>
References: <BLU179-W318A2EE492D30DDB9FB009DEF50@phx.gbl> <20A80B2E-42BB-486F-8F83-A6FDBEBA4056@ajf.me>,<5B708D89-B208-4644-BC89-1B7AE98A99BA@ajf.me> <BLU179-W594B8F1B1CF4F22E6F52BADEF30@phx.gbl> <6A40E21F-D265-4ADC-AD79-4EDB7AB45A01@ajf.me> <53D2AE01.8020806@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 25 Jul 2014, at 20:20, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> This makes very little sense, 0 means the same as false is in many
> contexts in PHP and also in many languages.

It also means very different things in some places, particularly return =
values. strpos returning 0 is most definitely not the same thing as =
strpos returning FALSE. That=92s a big reason why FALSE and TRUE aren=92t =
accepted for int type hints: bools are common error values.

> Having random arcane rules
> would only make the users curse us every time they get tripped by =
them.

The rules are not random nor arcane.

> I call everybody to vote against this RFC - it's better not to have =
such
> thing at all then to promise our users improvement only for them to
> discover this improvement is fraught with inconsistent arbitrary rules

How are they inconsistent and arbitrary? These rules haven=92t been =
picked at random from a hat, they=92ve come from a process of careful =
thought. Casting an integer to a string and vice-versa makes sense and =
is a common operation ($_GET[=91id=92]), while casting a NULL or FALSE =
to a string doesn=92t really make sense (when do you need to do this?), =
and is unlikely to happen unless something=92s gone wrong.

> that do not match what the rest of the language is doing

That is true, but it would be possible to change zpp later.

> - even within
> the same context of the function call. I can see no uniting principle
> behind this table, which is randomly strict and randomly non-strict
> without connection to the rest of PHP. I do not think it is the right
> thing to have such thing in the language, even if it would help
> somebody's particular use-case.

The point of this RFC is to strike a compromise that is generally useful =
rather than helping one specific use case (strict hints) or another =
(casts).

--
Andrea Faulds
http://ajf.me/