Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80572
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=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
Date: Thu, 15 Jan 2015 16:59:30 +0000
Cc: Zeev Suraski <zeev@zend.com>,
 Richard Quadling <RQuadling@gmail.com>,
 Leigh <leight@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A6B06BAB-F8C8-4BFC-98F5-21AD572D65A2@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me> <CALrkBjaBgvfdqLqSPDCGfHJD7XEOTOba9yg5ttHN7V1KyFA1-w@mail.gmail.com>
To: Mike Willbanks <pencap@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hello Mike,

> On 15 Jan 2015, at 16:55, Mike Willbanks <pencap@gmail.com> wrote:
>=20
> I actually quite disagree with that statement.

I don=E2=80=99t understand. I said "either approach to scalar hints will =
upset a large portion of the community=E2=80=9D. Are you not =
demonstrating that point, in that you don=E2=80=99t like the strict =
approach?

>  Both as a library/framework developer and a user land developer I =
find strict typing to be more of an issue.  For instance:
>=20
> function foo(int $foo)
> foo('23');
>=20
> This would be a pain and cause constant glue from userland:
> Option A: Force Cast aka (int) '23'
> Option B: Check for digits via ctype_digits then force cast
> etc.
>=20
> To provide more of a point here, variables coming from HTTP are always =
a string, this makes strict casting a troubling item, considering that =
the main way of fetching input is coming from the web specifically.  I'm =
certain this would also affect other areas as well such as reading csv =
files and more.  To me this point alone makes a vastly strong statement =
against strict typing and as such, it would make life far more difficult =
for library developers and user land developers alike.

Well, this RFC doesn=E2=80=99t force you to use strict type checking. =
Quite the opposite.


> I agree with the others in that declarative syntax to change it is a =
bad idea.  It actually reminds me of ECMAScript 5's "use strict" =
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_=
mode) condition.   Changing the definition based on user land scripts =
can lead to bugs and inconsistencies in a library developers purpose of =
a package and cause bad conditions.  It also means that then a library =
developer would need to handle conditions on both sides (when in weak =
vs. strict).

No, the library developer would never need to =E2=80=9Chandle both =
cases=E2=80=9D. Your library always gets the type it asks for. The RFC =
is quite clear on this. Your code will always behave exactly the same.

Thanks.

--
Andrea Faulds
http://ajf.me/