Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96138
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCijPyr8KGSOiHMDGANJpwDYbi8F8MrBc1MAUwJL-_berg@mail.gmail.com>
References: <CA+kxMuQqKL7=+7NEAT8Nh6cWofJkNkQj7ujm7Ksi2yW_6cH0dQ@mail.gmail.com>
 <CAEZPtU6o2eypGrQay-+eOtkU=V_03uJNQpaRr2MVwAGGgbz7-w@mail.gmail.com>
 <CAPwsocHWv5nQDufvTgJK4BkYsLidHxVD3NBAUkNXzOwL00kouA@mail.gmail.com>
 <006d8ac3-df7d-8890-5b60-56fbc9e856b1@gmx.de> <CANUQDCijPyr8KGSOiHMDGANJpwDYbi8F8MrBc1MAUwJL-_berg@mail.gmail.com>
Date: Mon, 26 Sep 2016 01:58:38 +0700
Message-ID: <CAEZPtU5pS9pqB0nnVuMaoOu3Gfp_seZDS2XakAsw+3XojDkQQA@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Dan Ackroyd <danack@basereality.com>, Christoph Becker <cmbecker69@gmx.de>, Leigh <leight@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c091dc2839a95053d59994e
Subject: Re: [PHP-DEV] [VOTE] get_class() disallow null parameter
From: pierre.php@gmail.com (Pierre Joye)

--94eb2c091dc2839a95053d59994e
Content-Type: text/plain; charset=UTF-8

On Sep 26, 2016 12:09 AM, "Niklas Keller" <me@kelunik.com> wrote:
>
> 2016-09-25 15:19 GMT+02:00 Christoph M. Becker <cmbecker69@gmx.de>:
>>
>> On 25.09.2016 at 11:29, Leigh wrote:
>>
>> > On Sun, 25 Sep 2016 at 06:29 Pierre Joye <pierre.php@gmail.com> wrote:
>> >
>> >> Also this behavior is clearly documented:
>> >>
>> >> http://th1.php.net/manual/en/function.get-class.php
>> >>
>> >> "If object is omitted when inside a class, the name of that class is
>> >> returned."
>> >>
>> >> I am opposed to break BC because we change our mind about how clean
is this
>> >> behavior and I recommend the (future) RMs to veto this change.
>> >
>> > This is ambiguous at best.
>> >
>> > "Omitted" and "Not omitted but set to null" are different things.
>>
>> However, the changelog entry for 5.3.0 states:
>>
>> | NULL became the default value for object, so passing NULL to object
>> | now has the same result as not passing any value.
>>
>> And that's what I would expect when reading the function signature;
>> after all, NULL is the default value of $object.
>
>
> I think what matters is the documentation of the return value, not the
changelog.
>
>> Returns the name of the class of which object is an instance. Returns
FALSE if object is not an object.
>>
>> If object is omitted when inside a class, the name of that class is
returned.
>
>
> It clearly says "omitted", that's passing nothing at all. Passing `null`
doesn't omit an argument, it passes `null`.
>
>>  I am opposed to break BC because we change our mind about how clean is
this
>
>
> I guess most code that might pass null is probably broken, do you have a
use case where the current behavior even makes sense?

Probably is sadly not a fact.

We restore it because it was breaking code. If I remember correctly it was
due to some other non existent features that allows the same  (or not
working).

All I am saying is this is a BC break with little to no value because what
willing to support 7.1+ only can simply use the alternatives.

--94eb2c091dc2839a95053d59994e--