Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83895
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain outlook.com designates 65.54.190.99 as permitted sender)
Message-ID: <BAY178-W418C61DF38879BED71640EDE140@phx.gbl>
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Thu, 26 Feb 2015 09:28:46 -0600
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: A different user perspective on scalar type declarations
From: theodorejb@outlook.com (Theodore Brown)

I am a full-time PHP developer responsible for maintaining several large=0A=
enterprise applications=2C as well as a number of libraries and personal ap=
ps.=0A=
I have been following the scalar type proposals quite closely=2C as along w=
ith=0A=
return type declarations=2C scalar types have the potential to reduce error=
s=2C=0A=
simplify API documentation=2C and improve static code analysis.=0A=
=0A=
I am in favor of Anthony's Scalar Type Declarations RFC=2C for two simple r=
easons:=0A=
=0A=
1. It doesn't change the behavior of existing weak types.=0A=
=0A=
PHP has long had an emphasis on backwards compatibility=2C and I'm worried =
that=0A=
those not in favor of strict types are treating backwards compatibility mor=
e=0A=
recklessly than they otherwise would in their fervor to avoid two ways of=
=0A=
handling scalar types. In my experience dealing with large enterprise apps=
=2C=0A=
however=2C there are hundreds of places where code relies on GET/POST param=
eters=0A=
being automatically trimmed when passed to a function expecting an integer.=
=0A=
The current coercive proposal would deprecate this and later make it an err=
or.=0A=
To avoid these notices/errors when upgrading=2C developers may take the "ea=
sy"=0A=
route of casting any input passed to a function expecting an int or float.=
=0A=
This is the same "too strict may lead to too lax" problem pointed out by th=
e=0A=
coercive RFC itself. There's a reason that integer handling was actually=0A=
*relaxed* back in PHP 5.1 (see http://php.net/manual/en/migration51.integer=
-parameters.php).=0A=
Why suddenly make the default more strict again?=0A=
=0A=
I am not against tightening up some of the default weak conversions (e.g. t=
o=0A=
not allow "99 bugs" for an int type)=2C but in my opinion this should be do=
ne=0A=
very carefully=2C and separately from any scalar type declaration proposal.=
=0A=
Major changes to the casting rules have the potential to seriously harm PHP=
 7=0A=
adoption=2C especially in enterprises with large amounts of legacy code. Th=
e=0A=
Scalar Type Declarations v0.5 RFC has the advantage here because it "just=
=0A=
works" when type hints are added to existing code in the default weak mode.=
=0A=
=0A=
2. Strict types are important in some cases.=0A=
=0A=
When it comes to authentication and financial calculations (a couple of are=
as=0A=
I routinely deal with) it is extremely important that errors are caught and=
=0A=
fixed early in the development process. In financial or security-sensitive=
=0A=
code=2C I would *want* any value with the wrong type (even a string like "2=
6")=0A=
to be flagged as an error when passed to a function expecting an integer.=
=0A=
=0A=
The option for type-based (rather than value-based) validation is equally=
=0A=
important when it comes to return types. Unless I have missed something=2C =
the=0A=
"Coercive Types for Function Arguments" RFC currently doesn't deal with ret=
urn=0A=
types at all (they aren't mentioned in the RFC). Would it handle scalar ret=
urn=0A=
types the same way as it does function arguments? If I declare a function t=
o=0A=
return an int=2C and I return a string instead (even if the string is numer=
ic)=2C=0A=
there are many cases where it would be an unintentional error. And if it=0A=
errors depending on the value=2C rather than the type=2C it often wouldn't =
be=0A=
possible to catch the problem statically.=0A=
=0A=
Here's a simple example of the advantage offered by strict types and static=
=0A=
analysis in the Scalar Type Declarations v0.5 RFC:=0A=
=0A=
<?php=0A=
declare(strict_types=3D1)=3B=0A=
=0A=
function getCustomerName(int $customerId): string=0A=
{=0A=
=A0=A0=A0 // look up customer name from database and return=0A=
}=0A=
=0A=
function getInvoiceByCustomer(int $customerId): Invoice=0A=
{=0A=
=A0=A0=A0 // retrieve invoice data and return object=0A=
}=0A=
=0A=
$id =3D filter_input(INPUT_GET=2C 'customer_id'=2C FILTER_VALIDATE_INT)=3B=
=0A=
=0A=
if ($id =3D=3D=3D false) {=0A=
=A0=A0=A0 echo 'Customer ID must be an integer'=3B=0A=
} else {=0A=
=A0=A0=A0 $customer =3D getCustomerName($id)=3B=0A=
=A0=A0=A0 $invoice =3D getInvoiceByCustomer($customer)=3B=0A=
=A0=A0=A0 // display invoice=0A=
}=0A=
=0A=
Strict types + static analysis can tell you that this will fail (because it=
's=0A=
based purely on types=2C and a string is being passed to a function expecti=
ng=0A=
an integer). Coercive typing cannot statically tell you that it will fail=
=2C=0A=
because it doesn't know whether the string passed to `getInvoiceByCustomer`=
=0A=
is acceptable as an integer without also knowing its value.=0A=
=0A=
To those who are worried that the addition of a strict mode will split the=
=0A=
community into separate camps=2C I would say "It's too late!" The community=
 has=0A=
already been split over this issue for years. Conceptually=2C the optional=
=0A=
strict mode proposed in Anthony's RFC is not very different from =3D=3D vs.=
 =3D=3D=3D=2C=0A=
or `in_array` with the $strict argument set to true. And I certainly am=0A=
glad that PHP offers these options!=0A=
=0A=
Theodore Brown=0A=
 		 	   		  =