I want to make two classes:
abstract class a {
abstract public function go($a);
}
final class b extends a {
abstract public function go(array $a);
}
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?
Ie, I can do the above, but not the following:
abstract class a {
abstract public function go(myClass $a);
}
final class b extends a {
abstract public function go(array $a);
}
I want to make two classes:
abstract class a {
abstract public function go($a);
}
final class b extends a {
abstract public function go(array $a);
}
Sorry, function in class b should not be abstract.
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?Ie, I can do the above, but not the following:
abstract class a {
abstract public function go(myClass $a);
}
final class b extends a {
abstract public function go(array $a);
}
Same, function in class b should not be abstract.
On Tuesday 29 April 2008 15:34:07 Sam Barrow wrote:
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?
That would be a bad idea, because it violates a (in my opinion, the) core
principle of OO: If B inherits from A, anything I can do with A (i.e. pass an
int to the method go) I can do with B.
http://en.wikipedia.org/wiki/Liskov_substitution_principle
Regards,
Stefan
P.S. Sorry if this pops up twice, used the wrong from: address at first ...
On Tuesday 29 April 2008 15:34:07 Sam Barrow wrote:
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?That would be a bad idea, because it violates a (in my opinion, the) core
principle of OO: If B inherits from A, anything I can do with A (i.e. pass an
int to the method go) I can do with B.
http://en.wikipedia.org/wiki/Liskov_substitution_principle
Yes this was my only doubt about it.
Regards,
StefanP.S. Sorry if this pops up twice, used the wrong from: address at first ...
Hi!
Sam Barrow wrote:
I want to make two classes:
abstract class a {
abstract public function go($a);
}
final class b extends a {
abstract public function go(array $a);
}
LSP violation here: a accepts go("away") but b doesn't.
This will not work, I get an error that the two must be compatible.
Wouldn't it be a good idea to allow any type hint for a parameter that
does not specify a type hint?
No, because of the LSP. Subtypes should not strengthen preconditions.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com