Declaration of Bar::__construct() must be compatible with that of Foo::__construct() View as Markdown

Hello Timm,

well for normal methods we must do that. The derived class must support the
same signature that the base class supports. In you example that would only
work if the derived method would have a default parameter for the additional
parameter:

<?php
class Foo {
function connect($server) {
}
}

class Bar extends Foo {
function connect($server, $port = NULL) {
}
}
?>

regards
marcus

Wednesday, February 25, 2004, 11:52:20 PM, you wrote:

Hello Timm,

i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules.

Neither should other methods follow this. What if I want to add a
non-default parameter to an overriden method?

<?php
class Foo {
function connect($server) {
}
}

class Bar extends Foo {
function connect($server, $port) {
}
}
?>>

I see where the problem comes from:

zend_do_perform_implementation_check() is called from
do_inherit_method_check() (both in zend_compile.c) which in turn is
called for inheritance and for interfaces. The behaviour is fully
desirable when implementing interfaces but not for regular inheritance.

• Timm

--
Best regards,
Marcus mailto:helly@php.net

Hello Timm,

i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules.

Neither should other methods follow this. What if I want to add a
non-default parameter to an overriden method?

Some test cases:

Should work #1, Bar::connect() adds an argument

<?php
interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect($server) { }
}

class Bar extends Foo {
function connect($server, $port) { }
}
?>

Should work #2, Bar::connect() might contain something such as
parent::connect('foo.example.com');

<?php
interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect($server) { }
}

class Bar extends Foo {
function connect() { }
}
?>

Should work #3, Bar::connect() might contain something such as
parent::connect($dsn->getHost());

<?php
class DSN { }

interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect($server) { }
}

class Bar extends Foo {
function connect(DSN $dsn) { }
}
?>

Should work #4, Foo::connect() adds a default argument

<?php
interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect($server, $port= 42) { }
}

class Bar extends Foo {
function connect($server, $port= 23) { }
}
?>

Should work #5, both interface and implementer have a default value
for the argument "server"

<?php
interface Connector {
function connect($server= 'localhost');
}

class Foo implements Connector {
function connect($server= 'localhost') { }
}

class Bar extends Foo {
function connect($server= 'localhost', $port= 23) { }
}
?>

Should work #6, implementation adds a default value

<?php
interface Connector {
function connect();
}

class Foo implements Connector {
function connect($server= 'localhost') { }
}

class Bar extends Foo {
function connect($server= 'localhost', $port= 23) { }
}
?>

Should NOT work #1, Foo doesn't fully implement connect()

<?php
interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect() { }
}

class Bar extends Foo {
function connect($server, $port) { }
}
?>

Should NOT work #2, class / primitive clash on argument

<?php
class DSN { }

interface Connector {
function connect(DSN $dsn);
}

class Foo implements Connector {
function connect($dsn) { }
}

class Bar extends Foo {
function connect($dsn) { }
}
?>

Should NOT work #3, Foo implements Connector::connect() incorrectly

<?php
interface Connector {
function connect($server);
}

class Foo implements Connector {
function connect($server, $port) { }
}

class Bar extends Foo {
function connect($server, $port= 23) { }
}
?>

Should NOT work #4, Foo implements Connector::connect() incorrectly

<?php
interface Connector {
function connect();
}

class Foo implements Connector {
function connect($server) { }
}

class Bar extends Foo {
function connect($server, $port) { }
}
?>

I would simply refrain from calling
zend_do_perform_implementation_check() in inheritance.

• Timm

Timm Friebe wrote:

Hello Timm,

i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules.

Neither should other methods follow this. What if I want to add a
non-default parameter to an overriden method?

Yes, I think this is the same issue that I brought up earlier related to
interfaces. I brought it up then as an inconsistency -- i.e. that you
couldn't override methods in interfaces & hence using interfaces was
limiting the OO inheritance that PHP supported when not using
interfaces. In brief the issue was that if you extend a class that
implemented an interface the extending class (subclass) had to also
implement the parent class' interface and was therefore not allowed to
override methods (w/ incompatible signatures) -- and not allowed to
implement a different interface which itself might specify incompatible
signatures.

It seems now that PHP is no longer inconsistent, but it also seems that
it is impossible to override methods w/ incompatible signature. Is that
a correct assessment? This is a pretty big difference from PHP4, then.
Personally, I can live with it :) -- just want to make sure I
understand it correctly.

Thanks,
Hans

Hello Andrey,

Thursday, February 26, 2004, 1:08:19 PM, you wrote:

Marcus Boerger wrote:

Hello Timm,

i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules. And as a
consequence maybe interfaces shouldn't allow constructors.

Does inheritance include visibility rules? ;)

You can only increase wivibility (pretected-> public) in a strict IS-A
modell as PHP uses.

--
Best regards,
Marcus mailto:helly@php.net