On 23 November 2023 20:31:09 GMT, Robert Landers <[email protected]>
wrote:
>I'd like to propose an RFC to enforce the covariance of constructors
>(just like is done for other methods), to take effect in PHP 9, with a
>deprecation notice in 8.3.x.
There's a lot more than visibility that is enforced on normal methods, but
isn't on constructors. For instance this is also valid:
class A {
public function __construct(int $foo) {}
}
class B extends A {
public function __construct(string $bar) {}
}
From a theoretical perspective, I think the argument is roughly that classes
aren't first-class citizens that you can pass around, so substitutability
doesn't apply. You can't for instance write a function that explicitly depends
on "a class definition inheriting from A", like this:
function foo(class<A> $class) {
$instance = new $class(42);
}
You can certainly simulate such code with some strings and maybe a bit of
reflection, but the language isn't going to make any guarantees about it.
I did just think of a counter-example, though, which is that "new
static($param)" is allowed, even though there's no way to know if $param will
be accepted by subclasses. Maybe it shouldn't be allowed?
From a practical point of view, it's often very useful to sub-class something
and provide a constructor with a different signature. Maybe your subclass has
additional dependencies; maybe it can hard-code or calculate some of the inputs
to the parent constructor for a special case, etc.
A private constructor can be used in conjunction with static methods to
simulate multiple named constructors (createFromString, createFromRequest,
etc). Given the lack of other guarantees, there's no particular gain in
preventing that just because the parent class has a public constructor.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
