php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61970 Restraining __construct() access level in subclass gives a fatal error
Submitted: 2012-05-07 18:40 UTC Modified: 2012-12-04 20:35 UTC
Votes:2
Avg. Score:4.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (50.0%)
From: postmaster at greg0ire dot fr Assigned:
Status: Closed Package: Class/Object related
PHP Version: 5.3.12 OS: Linux
Private report: No CVE-ID: None
 [2012-05-07 18:40 UTC] postmaster at greg0ire dot fr
Description:
------------
Restraining the __construct() method un a subtype gives a Fatal error.
As stated in the following resources, the LSP should not apply here.


- https://bugs.php.net/bug.php?id=40880
- http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle
- http://ralphschindler.com/2012/03/09/php-constructor-best-practices-and-the-prototype-pattern

Test script:
---------------
<?php

class Foo {
    public function __construct(){}
}

class Bar extends Foo {
    protected function __construct(){}
}

Expected result:
----------------
No output at all.

Actual result:
--------------
> PHP Fatal error:  Access level to Bar::__construct() must be public (as in class Foo) in /tmp/bug.php on line 9

> Fatal error: Access level to Bar::__construct() must be public (as in class Foo) in /tmp/bug.php on line 9

Patches

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-05-07 18:47 UTC] postmaster at greg0ire dot fr
fixed the title
 [2012-05-07 18:47 UTC] postmaster at greg0ire dot fr
-Summary: Restraining __constructor() access level in subclass gives a fatal error +Summary: Restraining __construct() access level in subclass gives a fatal error
 [2012-05-08 10:46 UTC] cataphract@php.net
It's true that PHP's behavior doesn't make a lot of sense from a theoretical perspective. However, there are some practical reasons why a different behavior would be -- arguably -- less desirable.

Namely, in PHP the constructor can be called from every instance method, even after construction. This makes it a necessity that the constructor act like regular instance methods. Consider:

<?php
class A {
private $a;
function __construct() { $this->a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}

Plus, PHP allows enforcing constructor signatures via interfaces. This means you have to enforce that signature throughout the hierarchy, and this includes not allows changing the visibility of the constructor.

Similarly, there's no principled reason to be unable to reduce the visibility in static methods. But PHP also prohibits such a pattern, like Java does, even though there's no overriding (the method in the superclass is said to be hidden). But PHP, like Java, allows calling static methods through an instance and through the subclass name. Then if you call the reduced visibility static method with the subclass name or a subclass instance, what would you do? Would it depend on the access of the caller has to the subclass method?
 [2012-05-08 13:04 UTC] postmaster at greg0ire dot fr
Thanks for the detailed answer, it is very informative, especially the first bit, which even shows the LSP could be applied in this case.
 [2012-12-04 19:10 UTC] pwolfenden at qualys dot com
I don't understand why the example described on [2012-05-08 10:46 UTC] by 
cataphract@php.net poses a problem.

I would expect class B to inherit reset(), which remains public. So what?

The point of the factory pattern, for example, is precisely to force the use of 
a single method to control the creation of new objects. And it is common OOP 
practice to implement this pattern using protected constructor methods. So it 
strikes me as bizzarre that PHP forces me to modify the whole class hierarchy if 
I want to enforce the use of a factory method for a derived class, and the base 
class has a public constructor.

Thank you, greg0ire, for opening this bug.
 [2012-12-04 20:35 UTC] postmaster at greg0ire dot fr
Perhaps I understood it one day, but now, I just can't recall why this example could be a problem.
@cataphract: maybe you could elaborate? I think the expected behavior would be the private constructor to be called when calling B::reset() ... To answer your questions, I would definitely take the caller access into account when calling the static methods.
 [2014-04-01 12:48 UTC] devoas at gmail dot com
There are some weak arguments here...

<?php
class A {
private $a;
function __construct() { $this->a = new stdclass; }
function reset() { $this->__construct(); }
}
class B extends A {
private function __construct() { } //what of reset() now?
}

Totally trivial case that fails to show anything at all. In reality child constructor can have significantly different arguments and there are no complaints about that (as it should be), and now supposedly such contrived case should mean anything? Why is LSP out with regards to arguments and not with regards to access level? This makes absolutely no sense!

Also someone somewhere was talking about how php would not know which constructor to call if child's one is private, if anyone wants to repeat this, this is also nonsense.

new B() --> Access exception, you see private constructor, stop looking, no need to dig to parents as that would just lead to incorrect behavior anyways.
 [2017-05-01 12:17 UTC] nikic@php.net
Automatic comment on behalf of mail@pmmaga.net
Revision: http://git.php.net/?p=php-src.git;a=commit;h=5324fb1f348f5bc979d9b5f13ac74177b73f9bf7
Log: Fixed bug #61970: Allow a child class to restrict access to ctor
 [2017-05-01 12:17 UTC] nikic@php.net
-Status: Open +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 04:01:31 2024 UTC