Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80073
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
Message-ID: <54A5E309.4050109@gmail.com>
Date: Thu, 01 Jan 2015 16:15:05 -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: Andrea Faulds <ajf@ajf.me>
CC: PHP Internals <internals@lists.php.net>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <54A466CB.9020400@gmail.com> <F4EB5BF5-E9B3-42C5-9291-88CB42A29207@ajf.me>
In-Reply-To: <F4EB5BF5-E9B3-42C5-9291-88CB42A29207@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> Yeah, it’s a problem. I think some breakage here is inevitable,
> unfortunately. Some of the classes with these names are stand-ins for
> scalar type hints, so that code can “just” migrate to using actual
> hints. But this doesn’t apply to all of them.

Breaking ZF2 and all software built on it is not "some breakage", it's a
serious issue which would produce a big barrier for PHP 7 migration. And
looks like there are more frameworks that do the same. This would be a
barrier to PHP 7 adoption, and note that is even for people that
couldn't care less for scalar typing. We'd find ourselves in python 3
situation - where people would be glad to upgrade but they use library X
and it doesn't work and they have no idea how to fix it and they keep
all their development on the old version and the new one never catches
on. It'd be a shame if we spend all this effort on PHP 7 and get no
adoption since people can't run their existing code on it.

> We could choose to simply not prohibit them as class names, but that
> creates a weird inconsistency where you can make ‘class Integer’ yet
> ‘function foo(Integer $a)’ hints against the integer type, not your
> class. Type hints are very widely used, so I doubt this would help
> anyone, and we’d still be breaking existing code type hinting against
> such classes.

I'd rather make the hints case sensitive. In fact, of two BC breakages
making classes case sensitive may be the lesser one (I'm not a big fan
of either but at least the modern frameworks would probably all work and
if some code does not it's possible to auto-fix it).

> There’s not much we can do really. I suppose there is one positive
> outcome, in that hopefully when broken code is updated to work, it
> might have more descriptive class names. :)

The issue here is that people that now use ZF2 or other framework like
that won't rewrite it. They would just stay on PHP 5.
-- 
Stas Malyshev
smalyshev@gmail.com