Re: [VOTE] get_class() disallow null parameter
| From: | Niklas Keller | Date: | Sun, 25 Sep 2016 17:09:52 +0000 |
| Subject: | Re: [VOTE] get_class() disallow null parameter | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-96136@lists.php.net to get a copy of this message | ||
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?
Regards, Niklas