Implementation for default parent constructors

[smalyshev]

Implementation for https://wiki.php.net/rfc/default_ctor

[dstogov]

This check may be not accurate enough to identify "parent::...".

[rayward]

Not sure what a default constructor achieves apart from encouraging flaky/risky code to be written.

From the PHP docs:

Unlike with other methods, PHP will not generate an E_STRICT level error message when __construct() is overridden with different parameters than the parent __construct() method has.

Constructors in a parent and child class can have a completely different signatures, so you shouldn't be calling a superclass' constructor without knowledge of what parameters it takes.

You mention in the RFC

Moreover, many of the internal classes, when extended, require the extending class to call parent constructor. Some others, however, do not have the constructor defined. Thus, the user has to guess, research or experiment in order to determine if parent constructor should be called or not.

I don't understand why a user researching if parent constructor is defined is a problem. Understanding code you're extending would seem like fairly normal practice. Generally if a parent class has a constructor then you should call it. Not doing so would probably cause undefined behaviour. If an internal class is missing documentation on its constructor then that's a documentation issue, not a language problem.

[rquadling]

@rayward Just trying to understand the issue on this.

Assume on day 1 I DO the work to find that there is no parent constructor. My implementation will not call parent::__construct().

On day 2, the API/library/extension gets updated and now DOES implement a constructor.

My code will not work, or at least could work in some very odd ways.

With the idea of "responsibility" (I don't know the right terms), when I write the code in my subclass __construct() method, I am responsible for what goes on. Once I've done my bit (or before, or around) I want to tell the parent that I am ready to let it do its job. It may or may not have anything to do.

Of course, the other side to this argument is that if on day 2 the parent class DOES now implement a constructor, it could radically change things anyway.

From my way of thinking, and as this is for PHP7 (so SOME BCs are going to happen), I think the parent constructor and destructor should both be callable from a subclass and if they are not defined they do not fail/error/warning.

If the class stack is significant (bad code smell, I know), a sub-sub-sub-sub class can say parent's, do your work and things will just bubble through the stack and pop at the top.

[smalyshev]

RFC declined.