Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83901
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
Reply-To: <francois@php.net>
To: "'Theodore Brown'" <theodorejb@outlook.com>,
	<internals@lists.php.net>
References: <BAY178-W418C61DF38879BED71640EDE140@phx.gbl>
In-Reply-To: <BAY178-W418C61DF38879BED71640EDE140@phx.gbl>
Date: Thu, 26 Feb 2015 17:05:43 +0100
Message-ID: <0a7a01d051de$12e68070$38b38150$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGwbbdURx2shUG2o7Zj2Ywptu8MnJ1C2jiw
Content-Language: fr
Subject: RE: [PHP-DEV] A different user perspective on scalar type declarations
From: francois@php.net (=?iso-8859-1?Q?Fran=E7ois_Laupretre?=)

Hi Theodore,

> De=A0: Theodore Brown [mailto:theodorejb@outlook.com]
>
> however, there are hundreds of places where code relies on GET/POST
> parameters
> being automatically trimmed when passed to a function expecting an
integer.
> The current coercive proposal would deprecate this and later make it =
an
> error.

Instead of rejecting the whole RFC, you can ask to keep supporting =
leading
and trailing blanks in numeric strings. That's something that is really
still under discussion, even between authors. To be clear, I prefer
authorizing leading and trailing blanks (but just blanks), Zeev prefers
restricting it, and I am not sure about Dmitry's preference. So you see =
it
is still open !

About BC, I don't think we are too lax with BC because developers would =
have
years to fix a pair of lines in their code. Running wordpress and other
large code just found 10 or 20 places where developers would have to =
change
something. So that's really minimal work and they have long years to do =
it.

> To avoid these notices/errors when upgrading, developers may take the
> "easy"
> route of casting any input passed to a function expecting an int or =
float.

That's possible but just much less often than they would do for 'strict
mode'.

> This is the same "too strict may lead to too lax" problem pointed out =
by
the
> coercive RFC itself. There's a reason that integer handling was =
actually
> *relaxed* back in PHP 5.1 (see
> http://php.net/manual/en/migration51.integer-parameters.php).
> Why suddenly make the default more strict again?

Agreed. But decision still open.

> I am not against tightening up some of the default weak conversions =
(e.g.
to
> not allow "99 bugs" for an int type), but in my opinion this should be
done
> very carefully, and separately from any scalar type declaration =
proposal.
> Major changes to the casting rules have the potential to seriously =
harm
PHP 7
> adoption, especially in enterprises with large amounts of legacy code. =
The
> Scalar Type Declarations v0.5 RFC has the advantage here because it =
"just
> works" when type hints are added to existing code in the default weak
> mode.

Our STH does not break anything. Maybe the newly-published version is =
more
clear. We propose implementing *exactly* the PHP5 logic and just raise
E_DEPRECATED messages that won't stop execution at all. Ignoring these
messages, there will be absolutely no difference in behavior with PHP 5.

> 2. Strict types are important in some cases.
>=20
> When it comes to authentication and financial calculations (a couple =
of
areas
> I routinely deal with) it is extremely important that errors are =
caught
and
> fixed early in the development process. In financial or =
security-sensitive
> code, I would *want* any value with the wrong type (even a string like
"26")
> to be flagged as an error when passed to a function expecting an =
integer.

Agreed. That's why, in the future, we may add new 'strict' type hint =
that
will accept nothing but their native type. We didn't add them here =
because
it would have been too confusing for a first release, and the whole
discussion is already complex enough. But I agree they can have some =
use.
The difference with the other RFC is that, we can add strict types in =
the
future but, is you choose the other RFC, it's a much more radical =
decision
because dual mode will remain forever.

> The option for type-based (rather than value-based) validation is =
equally
> important when it comes to return types. Unless I have missed =
something,
> the
> "Coercive Types for Function Arguments" RFC currently doesn't deal =
with
> return
> types at all (they aren't mentioned in the RFC). Would it handle =
scalar
return
> types the same way as it does function arguments?

Maybe not clear in the RFC but return types are handled exactly the same
way.

 If I declare a function to
> return an int, and I return a string instead (even if the string is
numeric),
> there are many cases where it would be an unintentional error. And if =
it
> errors depending on the value, rather than the type, it often wouldn't =
be
> possible to catch the problem statically.

Right. That's an additional argument in favor of introducing strict =
scalar
types in the future, as I said above.

> Here's a simple example of the advantage offered by strict types and
static
> analysis in the Scalar Type Declarations v0.5 RFC:
>=20
> <?php
> declare(strict_types=3D1);
>=20
> function getCustomerName(int $customerId): string
> {
> =A0=A0=A0 // look up customer name from database and return
> }
>=20
> function getInvoiceByCustomer(int $customerId): Invoice
> {
> =A0=A0=A0 // retrieve invoice data and return object
> }
>=20
> $id =3D filter_input(INPUT_GET, 'customer_id', FILTER_VALIDATE_INT);
>=20
> if ($id =3D=3D=3D false) {
> =A0=A0=A0 echo 'Customer ID must be an integer';
> } else {
> =A0=A0=A0 $customer =3D getCustomerName($id);
> =A0=A0=A0 $invoice =3D getInvoiceByCustomer($customer);
> =A0=A0=A0 // display invoice
> }
>=20
> Strict types + static analysis can tell you that this will fail =
(because
it's
> based purely on types, and a string is being passed to a function
expecting
> an integer). Coercive typing cannot statically tell you that it will =
fail,
> because it doesn't know whether the string passed to
> `getInvoiceByCustomer`
> is acceptable as an integer without also knowing its value.

If strict type hints are defined in the future, and if you use them in =
your
example, you will get exactly the same and static analysis will still be
able to find your bug. The difference is that you will decide to use =
them
only where you need to make it more strict, function by function, =
argument
by argument.

> To those who are worried that the addition of a strict mode will split =
the
> community into separate camps, I would say "It's too late!" The =
community
> has
> already been split over this issue for years. Conceptually, the =
optional
> strict mode proposed in Anthony's RFC is not very different from =
=3D=3D vs.
=3D=3D=3D,
> or `in_array` with the $strict argument set to true. And I certainly =
am
> glad that PHP offers these options!

Those choices are just additional options you may use in your code or =
not,
not a global switch between to global modes.

And, even if you consider the community is already split, we are very
idealistic and consider that it can be unified again ;)

Thanks for all. Tell me where I was not clear.

Fran=E7ois