info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Strange but true! Working with interfaces in PHP
10 views
Skip to first unread message
Mirco
Mar 31, 2014, 6:31:13 PM3/31/14
to
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?
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?
Jerry Stuckle
Apr 1, 2014, 12:43:59 PM4/1/14
to
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
jstu...@attglobal.net
==================
Christoph Michael Becker
Apr 3, 2014, 7:20:55 AM4/3/14
to
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:
>
> [code sample]
> 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:
>
>
> Running the above code, this is what I get: Fatal error: Declaration
> of B::match() must be compatible with that of IBaseB::match()
Confirmed on PHP 5.5.11.
> 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.
However, current PHP supports only invariance reliably. Consider the
following example:
class A {}
class B extends A {}
class C {function foo(A $var) {}}
class D extends C {function foo(B $var) {}}
The last line gives the following notice:
Strict standards: Declaration of D::foo() should be compatible with
C::foo(A $var)
It would be nice, if PHP accepts covariant type hints for function
parameters, but not doing it is not a bug. In this case it might be a
documentation bug, or rather a documentation omission -- at least I was
not able to find this behavior documented.
> The things become more strange if we look at another example. This
> one:
>
>
> Here, what I get it's not a Fatal Error, but a Catchable Fatal
> Error.
PHP 5.5.11 gives:
> Here, what I get it's not a Fatal Error, but a Catchable Fatal
> Error.
Catchable fatal error: Argument 1 passed to B::match() must implement
interface IA, instance of A given
> This is an error that could be catched by this simple
> function:
>
>
> 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.
One might argue whether a Fatal Error is more appropriate here. After
> 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.
all PHP is a dynamically typed language, and what is given here is only
a type *hint*, not a type declaration. In this case the program *could*
run without errors, because the $subject parameter is not used by the
function, and even if it was used, that doesn't necessarily imply that
the argument $a would be "incompatible". So a Catchable Fatal Error
might be more inline with PHP's dynamic typing.
PS: Please avoid overlong lines, because Google Groups can't properly
handle them.
--
Christoph M. Becker
Daniel Pitts
Apr 3, 2014, 10:19:38 AM4/3/14
to
On 3/31/14 3: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.
The error here has nothing to do with "A" or the type of "A". What it is
> 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.
saying is that "B::match(IA $subject)" is not compatible with
IBaseB::match(IBaseA $subject).
Think about it this way. If I ask for any "IBaseB" object, then I am
expecting to be able to pass in *any* IBaseA object to the match method.
However, your B::match won't accept just any old IBaseA object, but only
ones that implement IA as well.
So this is expected *and* desired.
Luuk
Apr 5, 2014, 4:50:07 AM4/5/14
to
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.....
> PS: Please avoid overlong lines, because Google Groups can't properly
> handle them.
So, i do not get the point of this statement...
Message has been deleted
Luuk
Apr 5, 2014, 5:28:59 AM4/5/14
to
On 5-4-2014 12:20, Tim Streater wrote:
> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.lan>
> I think some extra words crept into the PS above, which should have
> read:
>
> PS: Please avoid Google Groups.
>
that makes more sence .....
> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.lan>
> read:
>
> PS: Please avoid Google Groups.
>
that makes more sence .....
Christoph Michael Becker
Apr 5, 2014, 8:21:53 AM4/5/14
to
Tim Streater wrote:
> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.lan>
> wrote:
>
> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.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
>> > PS: Please avoid overlong lines, because Google Groups can't properly
>> > handle them.
>>
>> But my client can.....
sections? I doubt so, because I'm using Thunderbird, too.
>> So, i do not get the point of this statement...
>
> I think some extra words crept into the PS above, which should have
> read:
>
> PS: Please avoid Google Groups.
IMHO, posting via Google Groups is okay, as long as one would be able to
> read:
>
> PS: Please avoid Google Groups.
work around its flaws, and adheres to generally agreed netiquette.
--
Christoph M. Becker
Luuk
Apr 5, 2014, 9:00:22 AM4/5/14
to
On 5-4-2014 14:21, Christoph Michael Becker wrote:
> Tim Streater wrote:
>
>> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.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 ;)
> Tim Streater wrote:
>
>> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.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.
>
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
Christoph Michael Becker
Apr 5, 2014, 9:28:54 AM4/5/14
to
Luuk wrote:
> On 5-4-2014 14:21, Christoph Michael Becker wrote:
>> Tim Streater wrote:
>>
>>> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.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 ;)
The longest line in the body of the OP[1] had 248 characters.
> On 5-4-2014 14:21, Christoph Michael Becker wrote:
>> Tim Streater wrote:
>>
>>> In article <4ns41b-...@luuk.invalid.lan>, Luuk <lu...@invalid.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
case I worked around the problem by snipping the code samples and
automatically reformatting the rest of the message.
[1] <news:bdfad044-74c3-4256...@googlegroups.com>
--
Christoph M. Becker
0 new messages