[RFC][Discussion] Why can constructors violate LSP?

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]

On Thu, Nov 23, 2023 at 5:31 PM Robert Landers landers.robert@gmail.com
wrote:

Hello Internals,

As you may know, an inherited method cannot reduce the visibility of
an overridden method. For example, this results in a fatal error
during compilation:

class P {
public function hello($name = 'world') {
echo "hello $name\n";
}
}

class C extends P {
private function hello($name = 'world') {
parent::hello($name);
echo "goodbye $name\n";
}
}

However, we can make certain methods private anyway, namely,
constructors (I haven't gone hunting for other built-in methods yet).
This is perfectly allowed:

class P {
public function __construct($name = 'waldo') {
echo "hello $name\n";
}
}

class C extends P {
private function __construct($name = 'world') {
parent::__construct($name);
echo "goodbye $name\n";
}
}

To my somewhat trained eye, this appears to violate the Liskov
Substitution Principle, for example, this now can have hidden errors:

function create(P $class) {
return new (get_class($class))();
}

proven by:

$c = (new ReflectionClass(C::class))
->newInstanceWithoutConstructor();

create($c);

Even though we thought we knew that the constructor was declared public.

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.

I'm more than happy to implement it.

Does anyone feel strongly about this one way or the other?

Constructors are an implementation detail of a specialized class and as
such they're not subject to LSP because the goal of LSP is to be able to
make sure that any object of a given type hierarchy can be used to
accomplish a certain behavior. If you take a step back from PHP's
dynamic nature and think about LSP from a more pure type system, the fact
you're expecting an object of type C, but then you completely disregard
everything about the object itself and dive into it's metadata to build
another object, that's the moment you're no longer playing by the rules of
OOP. It's like those mathematical equations that prove that 1 = 2, they all
have one thing in common: they end up dividing by 0 at some point.

OOP here dictates that you should reach for patterns like Builder, Abstract
Factory or similar. That way you constraint yourself to the rules of OOP
and you won't get weird outcomes.

From another point of view, when a type is expected by a function or
method, all we can expect from it is whatever was defined as the blueprint
(class/interface) of that object and the __construct() is a special method
that is not assumed to be part of that blueprint because it's not
reasonable to do $object->__construct(); after receiving an object. As
such, a constructor cannot break LSP because the constructor is not part of
the object's API from a "receptor" point of view.

I don't have a vote so take my opinion with a bucket of salt, but if I
could I would definitely vote against such RFC.

--
Marco Deleu

On Thu, Nov 23, 2023 at 12:31 PM Robert Landers
landers.robert@gmail.com wrote:

Hello Internals,

As you may know, an inherited method cannot reduce the visibility of
an overridden method. For example, this results in a fatal error
during compilation:

class P {
public function hello($name = 'world') {
echo "hello $name\n";
}
}

class C extends P {
private function hello($name = 'world') {
parent::hello($name);
echo "goodbye $name\n";
}
}

However, we can make certain methods private anyway, namely,
constructors (I haven't gone hunting for other built-in methods yet).
This is perfectly allowed:

class P {
public function __construct($name = 'waldo') {
echo "hello $name\n";
}
}

class C extends P {
private function __construct($name = 'world') {
parent::__construct($name);
echo "goodbye $name\n";
}
}

To my somewhat trained eye, this appears to violate the Liskov
Substitution Principle, for example, this now can have hidden errors:

function create(P $class) {
return new (get_class($class))();
}

proven by:

$c = (new ReflectionClass(C::class))
->newInstanceWithoutConstructor();

create($c);

Even though we thought we knew that the constructor was declared public.

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.

I'm more than happy to implement it.

Does anyone feel strongly about this one way or the other?

Robert Landers
Software Engineer
Utrecht NL

Hi Robert,

Liskov and Wing explicitly exempted constructors in their original
paper describing the principle:
http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.pdf

4.1 Type Specifications

A type specification includes the following information:

• The type's name
• A description of the type's value space
• A definition of the type's invariant and history properties
• For each of the type's methods:
  • Its name;
  • Its signature including signaled exceptions;
  • Its behavior in terms of pre-conditions and post-conditions.

Note that the creators are missing. Omitting creators allows subtypes to provide different creators than their supertypes. In addition, omitting creators makes it easy for a type to have multiple implementations, allows new creators to be added later, and re ects common usage: for example, Java interfaces and virtual types provide no way for users to create objects of the type.

(Creators is Liskov's word for constructors, which they later define
in the paper.)

Hope that helps.

• Mark Trapp

Hello Internals,

As you may know, an inherited method cannot reduce the visibility of
an overridden method. For example, this results in a fatal error
during compilation:

class P {
public function hello($name =3D 'world') {
echo "hello $name\n";
}
}

class C extends P {
private function hello($name =3D 'world') {
parent::hello($name);
echo "goodbye $name\n";
}
}

However, we can make certain methods private anyway, namely,
constructors (I haven't gone hunting for other built-in methods yet).
This is perfectly allowed:

class P {
public function __construct($name =3D 'waldo') {
echo "hello $name\n";
}
}

class C extends P {
private function __construct($name =3D 'world') {
parent::__construct($name);
echo "goodbye $name\n";
}
}

To my somewhat trained eye, this appears to violate the Liskov
Substitution Principle, for example, this now can have hidden errors:

function create(P $class) {
return new (get_class($class))();
}

proven by:

$c =3D (new ReflectionClass(C::class))
->newInstanceWithoutConstructor();

create($c);

Even though we thought we knew that the constructor was declared public.

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.

I'm more than happy to implement it.

Does anyone feel strongly about this one way or the other?

Robert Landers
Software Engineer
Utrecht NL

(Apologies: resending because I used the wrong email address to send
to the list)

Hi Robert,

Liskov and Wing explicitly exempted constructors in their original
paper describing the principle:
http://reports-archive.adm.cs.cmu.edu/anon/1999/CMU-CS-99-156.pdf

4.1 Type Specifications

A type specification includes the following information:

• The type's name
• A description of the type's value space
• A definition of the type's invariant and history properties
• For each of the type's methods:
  • Its name;
  • Its signature including signaled exceptions;
  • Its behavior in terms of pre-conditions and post-conditions.

Note that the creators are missing. Omitting creators allows subtypes to =
provide different creators than their supertypes. In addition, omitting cre=
ators makes it easy for a type to have multiple implementations, allows new=
creators to be added later, and re ects common usage: for example, Java in=
terfaces and virtual types provide no way for users to create objects of th=
e type.

(Creators is Liskov's word for constructors, which they later define
in the paper.)

Hope that helps.

• Mark Trapp

Hi Robert,

Am 23.11.23 um 21:31 schrieb Robert Landers:

However, we can make certain methods private anyway, namely,
constructors (I haven't gone hunting for other built-in methods yet).
This is perfectly allowed:

class P {
public function __construct($name = 'waldo') {
echo "hello $name\n";
}
}

class C extends P {
private function __construct($name = 'world') {
parent::__construct($name);
echo "goodbye $name\n";
}
}

you can enforce a public constructor by using an interface:

interface X {
     public function __construct (int $foo);
}

class A implements X {
     public function __construct (int $foo) {
         echo __CLASS__ . ": $foo\n";
     }
}

class B extends A {
     private function __construct (int $foo) {
         echo __CLASS__ . ": $foo\n";
     }
}

Which will give you the following error:
PHP Fatal error:  Access level to B::__construct() must be public (as in
class X) in test.php on line 14

That way you put the definition of the constructor into the contract.

Greets
Dennis