On Jul 23, 2014, at 11:37, Andrea Faulds <[email protected]> wrote:
> Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names
> 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’s approach with Hack, which removes the aliases entirely for type
> 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’s so closely related, the
inconsistency is itself inconsistent.
Although I don’t have voting rights, I would completely support a separate RFC
to remove the aliases in PHP 6/7. But in the mean time, as long as they’re
still in the language, I think they need to be fully supported anywhere their
“real” counterparts can be used. Hack didn’t just remove them in some cases, it
removed them across the board. And I think that’s the right approach: they’re
supported across the board until they’re no longer supported, and then they’re
not supported anywhere.
> So, yes it does permit non-decimal numbers, but it’s a bug I need to fix.
I’m not sure I follow. If I have function foo(int $bar) {}, what happens in
these cases:
foo(0x2f);
foo(‘0x2f’);
Related, is “numeric" basically the union of “int” and “float” (as appears to
be the case from the chart in the RFC), or is it something more along the lines
of is_numeric()? There could be consistency issues lurking 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
delete this e-mail, including attachments without reading or saving them in any
manner. The unauthorized use, dissemination, distribution, or reproduction of
this e-mail, including attachments, is prohibited and may be unlawful. If you
have received this email in error, please notify us immediately by e-mail or
telephone and delete the e-mail and the attachments (if any).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
