# Inheritance/compatibility behavior

- Thread: https://externals.io/message/37292
- Original archive: https://news-web.php.net/php.internals/37292
- Started by Sam Barrow on 2008-04-29T13:34:07+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #37292 — Sam Barrow — 2008-04-29T13:34:07+00:00

URL: https://externals.io/message/37292#37292

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);
}

---

## #37293 — Sam Barrow — 2008-04-29T13:35:50+00:00

URL: https://externals.io/message/37292#37293 · In reply to: #37292

> 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.

---

## #37301 — Sam Barrow — 2008-04-29T15:41:55+00:00

URL: https://externals.io/message/37292#37301 · In reply to: #37299

> On Tuesday 29 April 2008 15:34:07 Sam Barrow wrote:
> 
> > […]
> 
> 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,
> Stefan
> 
> P.S. Sorry if this pops up twice, used the wrong from: address at first ...

---

## #37299 — Stefan Walk — 2008-04-29T15:43:22+00:00

URL: https://externals.io/message/37292#37299 · In reply to: #37292

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 ...

---

## #37307 — Stanislav Malyshev — 2008-04-29T16:11:18+00:00

URL: https://externals.io/message/37292#37307 · In reply to: #37292

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