On Sep 26, 2016 12:09 AM, "Niklas Keller" <m...@kelunik.com> wrote: > > 2016-09-25 15:19 GMT+02:00 Christoph M. Becker <cmbecke...@gmx.de>: >> >> On 25.09.2016 at 11:29, Leigh wrote: >> >> > On Sun, 25 Sep 2016 at 06:29 Pierre Joye <pierre....@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.
