Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95181
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender)
To: Stanislav Malyshev <smalyshev@gmail.com>,
 Dan Ackroyd <danack@basereality.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CA+kxMuSgm_45x-VbmSpKdOdJbPC6WrcH=7Ut8ZWHOceNC5-XsA@mail.gmail.com>
 <0d1e3cfc-f5df-474d-f8dc-c806bec0e412@gmx.de>
 <3e7c038b-0e1a-bf7e-c3bf-46594bf13157@gmail.com>
Message-ID: <2f759ec3-4207-1541-4f5f-9080e9f2cbbe@gmx.de>
Date: Mon, 15 Aug 2016 12:38:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3e7c038b-0e1a-bf7e-c3bf-46594bf13157@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] get_class() disallow null parameter
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 15.08.2016 at 02:09, Stanislav Malyshev wrote:

>> Prohibiting `get_class(NULL)` is certainly a good idea, but I have some
>> concerns regarding BC.  While `__CLASS__` has been introduced with PHP
>> 4.3.0, it had the glitch to return the lower-cased class name before PHP
>> 5.0.0.  So there *might* still be PHP 5 code around using `get_class(NULL)`.
> 
> I note that this (i.e. behavior proposed in the RFC) was briefly the
> case for 5.3.0 and was changed to current behavior for 5.3.1. But
> pre-5.3 versions return false when NULL is passed to get_class, with no
> message.
> 
> So, old PHP code doesn't seem to be a problem only one that was written
> after 5.3.1, because it doesn't look like get_class(NULL) worked before
> it: https://3v4l.org/4QvCs

Thanks for pointing this out.  Interestingly, indicated by a changelog
entry in the get_class() manual, the behavior is somewhat different when
no argument is passed, see <https://3v4l.org/sWX9X>.  That works as
least as of PHP 5.2.0; not sure why 5.0 and 5.1 fail here.

As the proposed behavior had been introduced with 5.3.0 and reverted
shortly after, indicates that we should be careful here.  Deprecating
for 7.2 and removing with 8.0 seems to be the safer way.

-- 
Christoph M. Becker