| Strange but true! Working with interfaces in PHP [message #185450] |
Mon, 31 March 2014 18:31  |
Mirco
Messages: 1
Registered: March 2014
Karma: 0
|
Junior Member |
add to buddy list
ignore all messages by this user
|
|
I was working on a software of arbitrary complexity when I stumbled upon this strange behavior of the PHP compiler.
Problem:
I have these interfaces and classes:
interface IBaseA {
}
interface IA extends IBaseA {
}
interface IBaseB {
public function match( IBaseA $subject );
}
interface IB extends IBaseB{
}
class A implements IA{
}
class B implements IB{
public function match( IA $subject ){
echo "Am I working? o_O<hr>";
}
}
$a = new A();
$b = new B();
$b->match($a);
Running the above code, this is what I get:
Fatal error: Declaration of B::match() must be compatible with that of IBaseB::match()
This behavior is very odd, because A implements IA that extends from IBaseA. So IA is an interface of type IBaseA. Methods I will put in IBaseA will be also in IA.
Class B accepts, in the match() method, an instance of IA.
Class B extends from IBaseB that in turn accepts an instance of IBaseA.
B should accept IA. In fact the interface that B implements accepts a more specific version of IA, but the Fatal Error still pops up.
The things become more strange if we look at another example.
This one:
interface IBaseA {
}
interface IA extends IBaseA {
}
interface IBaseB {
public function match( IA $subject );
}
interface IB extends IBaseB{
}
class A implements IBaseA{
}
class B implements IB{
public function match( IA $subject ){
echo "Am I working? o_O<hr>";
}
}
$a = new A();
$b = new B();
$b->match($a);
Here, what I get it's not a Fatal Error, but a Catchable Fatal Error.
This is an error that could be catched by this simple function:
function myErrorHandler($errno, $errstr, $errfile, $errline) {
if ( E_RECOVERABLE_ERROR===$errno ) {
echo "'catched' catchable fatal error<br>";
return true;
}
return false;
}
set_error_handler('myErrorHandler');
This time though, the compiler should not let me continue with the execution because:
B implements IB that extends from IBaseB.
IBaseB accepts instances of IA.
IA extends from IBaseA.
A implements IBaseA.
What i'm passing to the match() method of B is an instance of A, that is more strict that IA.
The compiler should throw a Fatal Error and it shouldn't let me continue with the execution! The inner details of B's match() implementation require an instance of IA with its own specific methods that could not be provided by IA's father, IBaseA.
Would you please shed a light onto this one?
What do you think about it?
|
|
|
|
| Re: Strange but true! Working with interfaces in PHP [message #185456 is a reply to message #185450] |
Tue, 01 April 2014 12:43  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
add to buddy list
ignore all messages by this user
|
|
On 3/31/2014 6:31 PM, Mirco wrote:
> I was working on a software of arbitrary complexity when I stumbled upon this strange behavior of the PHP compiler.
>
> Problem:
> I have these interfaces and classes:
>
> interface IBaseA {
>
> }
>
> interface IA extends IBaseA {
>
> }
>
> interface IBaseB {
>
> public function match( IBaseA $subject );
>
> }
>
> interface IB extends IBaseB{
> }
>
> class A implements IA{
>
> }
>
> class B implements IB{
> public function match( IA $subject ){
> echo "Am I working? o_O<hr>";
> }
> }
>
> $a = new A();
> $b = new B();
> $b->match($a);
>
> Running the above code, this is what I get:
> Fatal error: Declaration of B::match() must be compatible with that of IBaseB::match()
>
> This behavior is very odd, because A implements IA that extends from IBaseA. So IA is an interface of type IBaseA. Methods I will put in IBaseA will be also in IA.
> Class B accepts, in the match() method, an instance of IA.
> Class B extends from IBaseB that in turn accepts an instance of IBaseA.
>
> B should accept IA. In fact the interface that B implements accepts a more specific version of IA, but the Fatal Error still pops up.
>
> The things become more strange if we look at another example.
> This one:
>
> interface IBaseA {
>
> }
>
> interface IA extends IBaseA {
>
> }
>
> interface IBaseB {
>
> public function match( IA $subject );
>
> }
>
> interface IB extends IBaseB{
> }
>
> class A implements IBaseA{
>
> }
>
> class B implements IB{
> public function match( IA $subject ){
> echo "Am I working? o_O<hr>";
> }
> }
>
> $a = new A();
> $b = new B();
> $b->match($a);
>
> Here, what I get it's not a Fatal Error, but a Catchable Fatal Error.
> This is an error that could be catched by this simple function:
>
> function myErrorHandler($errno, $errstr, $errfile, $errline) {
> if ( E_RECOVERABLE_ERROR===$errno ) {
> echo "'catched' catchable fatal error<br>";
> return true;
> }
> return false;
> }
> set_error_handler('myErrorHandler');
>
> This time though, the compiler should not let me continue with the execution because:
>
> B implements IB that extends from IBaseB.
> IBaseB accepts instances of IA.
> IA extends from IBaseA.
> A implements IBaseA.
>
> What i'm passing to the match() method of B is an instance of A, that is more strict that IA.
> The compiler should throw a Fatal Error and it shouldn't let me continue with the execution! The inner details of B's match() implementation require an instance of IA with its own specific methods that could not be provided by IA's father, IBaseA.
>
> Would you please shed a light onto this one?
> What do you think about it?
>
Mirco,
You didn't say what version of PHP you're running, so it's hard to
pinpoint exactly. However, Zend has had problems with inheritance in
the past; I would consider the first of these to be a bug. I think
you're correct - the code should work.
In the second case, I agree that this could be a runtime error, but I
also agree this should not be a catchable error. However when you set
an error handler, what happens after that is your responsibility. PHP
allows you to continue after a runtime error. Note the statement in the
PHP doc under set_error_handler:
"Also note that it is your responsibility to die() if necessary. If the
error-handler function returns, script execution will continue with the
next statement after the one that caused an error."
So this would be correct operation, IMHO.
I would suggest you submit a bug on the first problem and see what they
say. See http://bugs.php.net.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: "overlong lines" [message #185498 is a reply to message #185497] |
Sat, 05 April 2014 09:00 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
add to buddy list
ignore all messages by this user
|
|
On 5-4-2014 14:21, Christoph Michael Becker wrote:
> Tim Streater wrote:
>
>> In article <4ns41b-hje(dot)ln1(at)luuk(dot)invalid(dot)lan>, Luuk <luuk(at)invalid(dot)lan>
>> wrote:
>>
>>> On 3-4-2014 13:20, Christoph Michael Becker wrote:
>>>> PS: Please avoid overlong lines, because Google Groups can't properly
>>>> handle them.
>>>
>>> But my client can.....
>
> Does your client really wrap overlong lines without distorting code
> sections? I doubt so, because I'm using Thunderbird, too.
>
I did not notice any such lines in the code that is snipped away now ;)
And i dont mind my news reader doing that, because if i want to look at
the source code, i copy/paste this in an editor (like Notepad++ ), so i
get syntax highlighting
|
|
|
|
|
|
Calendar
Search
Help
Members
Control Panel
Logout [ CommonCrawl [Bot] ]
Home
]