Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75978
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thesba.com designates 208.106.205.210 as permitted sender)
To: "internals@lists.php.net >> PHP Internals" <internals@lists.php.net>
Date: Wed, 23 Jul 2014 14:17:14 -0700
Thread-Topic: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Thread-Index: Ac+mu3mwykhgBhutR26O7OInVDgGOA==
Message-ID: <8291F95E-7FD5-4AF7-8CF6-EBDDE9E8AF05@newtekbusinessservices.com>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
 <53C2178E.7070705@sugarcrm.com> <53CB70BC.4020001@php.net>
 <53CC0A75.6010200@sugarcrm.com>
 <7E1578C5-30DE-46CE-B3CA-AFA9F7FA1B6B@thesba.com>
 <53C02C31-BE27-4235-AF25-AE319067FD94@ajf.me>
In-Reply-To: <53C02C31-BE27-4235-AF25-AE319067FD94@ajf.me>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: rewilliams@thesba.com (Robert Williams)

On Jul 23, 2014, at 11:37, Andrea Faulds <ajf@ajf.me> wrote:

> Aliases mean inconsistency. We shouldn=92t unnecessarily have multiple na=
mes for the same thing, just one. Also, for every alias we support, another=
 reserved word is added. Hence we only allow one set of names. This is also=
 Facebook=92s approach with Hack, which removes the aliases entirely for ty=
pe casting. I might propose we deprecate/remove the aliases in a future RFC=
.

I agree the aliases, by definition, represent inconsistency. However, that =
inconsistency is already in the language, and those keywords already exist.=
 By not supporting the aliases in new functionality that=92s so closely rel=
ated, the inconsistency is itself inconsistent.

Although I don=92t have voting rights, I would completely support a separat=
e RFC to remove the aliases in PHP 6/7. But in the mean time, as long as th=
ey=92re still in the language, I think they need to be fully supported anyw=
here their =93real=94 counterparts can be used. Hack didn=92t just remove t=
hem in some cases, it removed them across the board. And I think that=92s t=
he right approach: they=92re supported across the board until they=92re no =
longer supported, and then they=92re not supported anywhere.

> So, yes it does permit non-decimal numbers, but it=92s a bug I need to fi=
x.

I=92m not sure I follow. If I have function foo(int $bar) {}, what happens =
in these cases:

   foo(0x2f);
   foo(=910x2f=92);

Related, is =93numeric" basically the union of =93int=94 and =93float=94 (a=
s appears to be the case from the chart in the RFC), or is it something mor=
e along the lines of is_numeric()? There could be consistency issues lurkin=
g here, too.


Regards,
Bob

--
Robert E. Williams, Jr.
Senior Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/


Notice: This communication, including attachments, may contain information =
that is confidential. It constitutes non-public information intended to be =
conveyed only to the designated recipient(s). If the reader or recipient of=
 this communication is not the intended recipient, an employee or agent of =
the intended recipient who is responsible for delivering it to the intended=
 recipient, or if you believe that you have received this communication in =
error, please notify the sender immediately by return e-mail and promptly d=
elete this e-mail, including attachments without reading or saving them in =
any manner. The unauthorized use, dissemination, distribution, or reproduct=
ion of this e-mail, including attachments, is prohibited and may be unlawfu=
l. If you have received this email in error, please notify us immediately b=
y e-mail or telephone and delete the e-mail and the attachments (if any).