Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80163
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
Message-ID: <54A9D39F.8010808@gmail.com>
Date: Sun, 04 Jan 2015 15:58:23 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
CC: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A466CB.9020400@gmail.com> <alpine.DEB.2.11.1501041727320.4080@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.11.1501041727320.4080@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> That's in a namespace, so it's not actually Integer, but 
> Zend\Db\Metadata\Type\Integer

Right, but it doesn't matter - in the same namespace (and in ones with
suitable imports), foo(Integer $bar) still means the class, not the
primitive type, and that would be broken by this RFC. Also, if integer
becomes reserved word, you won't be able to write "class Integer"
anymore, regardless of the namespace.

> With namespaces (as in your above examples), this is already moot.

I'm sorry, I don't see how this is moot if we still have the breakage as
described above.

> I think it's perfectly acceptable that PHP makes a built-in type a 
> reserved word. I would certainly not change it to PHPInt to "avoid any 
> obvious clashes".

As I already pointed out, if we make it reserved word we'll have BC
problem. We already had this experience when goto became reserved word -
it resulted in a lot of breakage. This would be bigger, since we adding
more reserved words and we know they are used in a lot of class names
(and, possibly, method names too).
-- 
Stas Malyshev
smalyshev@gmail.com