Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Interface inheritance »

Interface inheritance

php.internals

Zeev Suraski

22 years ago
All, Yesterday, someone complained that classes that implement interfaces succeed in doing so even when they don't satisfy the prototypes. While this does cause an E_STRICT message to be emitted, it would go unnoticed in most cases, as E_STRICT is off by default, in some cases - even when people think it's on. I believe that this behavior is wrong. I believe that classes should not be allowed to say they implement an interface X, unless they actually implement all of the methods in that interface with methods that are compatible with its prototypes. Reasoning: - Interfaces (and for that matter, abstract classes) are a new feature in PHP 5, used solely to enforce implementing classes to abide to the prototypes. There's no issue of downwards compatibility, and there's no other use case. - Without this, the whole mechanism of class type hints is rendered useless. With it, it gives users the full power of class type hints (and instanceof, for that matter) - because they always have the option of adding an interface for their base classes. Suggested behavior: Any method that implements (directly or indirectly) an interface method or an abstract method, will have implementation checks fully enforced, with an E_COMPILE_ERROR emitted in case of an error. Behavior for methods that override regular parent methods, that do not have interface/abstract prototypes, will not change (E_STRICT message). Comments welcome - we'd like to sort this out before RC2... Zeev

Derick Rethans

22 years ago
On Mon, 19 Apr 2004, Zeev Suraski wrote:
> Suggested behavior: > Any method that implements (directly or indirectly) an interface method or > an abstract method, will have implementation checks fully enforced, with an > E_COMPILE_ERROR emitted in case of an error. > Behavior for methods that override regular parent methods, that do not have > interface/abstract prototypes, will not change (E_STRICT message). > > Comments welcome - we'd like to sort this out before RC2...
Sounds good... I already thought we were doing this. regards, Derick

Christian Schneider

22 years ago
Zeev Suraski wrote:
> Any method that implements (directly or indirectly) an interface method > or an abstract method, will have implementation checks fully enforced, > with an E_COMPILE_ERROR emitted in case of an error.
Excuse my ignorance: What is defined as fully implementing the interface? I guess all methods have to be implemented with all the parameters having the same type if specified, right? What about extending the parameter set, especially with default values? E.g. is foo(A $a, $newparam = 'false) valid for foo(A $a)? - Chris

Andi Gutmans

22 years ago
Hey, I just wanted to note the fact that I disagree with this. In a perfect world, I would go with an E_COMPILE_ERROR in all situations; when inheriting regular classes (w/o abstract methods), abstract methods and interfaces. That is what the academic part of me feels but knows can't be done. As this would break BC too much, I agree that inheriting from regular classes should not lead to an error. I believe that for consistency sake interfaces and abstract classes should behave the same as regular classes, thus, if regular classes don't cause an error, the former also shouldn't. I propose to leave things the way they are: a) In E_STRICT error_reporting there's an E_STRICT warning when overriding a method with an incompatible signature (for all cases). b) PHP will keep BC compatibility for old classes and consistency between them and the new classes. This way old classes and new classes/interfaces will all behave the same. That said, if the majority of people prefer the more aggressive approach of E_COMPILE_ERROR with interfaces and abstract methods, it can be changed. Andi At 11:49 AM 4/19/2004 +0300, Zeev Suraski wrote:

Sebastian Bergmann

22 years ago
Andi Gutmans wrote:
> aggressive approach of E_COMPILE_ERROR
+1 :)
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Andi Gutmans

22 years ago
For interfaces and abstract methods? At 12:17 PM 4/19/2004 +0200, Sebastian Bergmann wrote:

Sebastian Bergmann

22 years ago
Andi Gutmans wrote:
> For interfaces and abstract methods?
Both.
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Andi Gutmans

22 years ago
And regular old-style inheritance? At 12:45 PM 4/19/2004 +0200, Sebastian Bergmann wrote:

Sebastian Bergmann

22 years ago
Andi Gutmans wrote:
> And regular old-style inheritance?
If you mean class Foo { public function doSomething($a, $b) {} } class Bar extends Foo { public function doSomething($c, $d, $e) {} } by "regular old-style inheritance" then no. It would not make sense to do so in PHP because we don't have multimethod dispatch.
-- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Zeev Suraski

22 years ago
At 13:01 19/04/2004, Christian Schneider wrote:
>Zeev Suraski wrote: >>Any method that implements (directly or indirectly) an interface method >>or an abstract method, will have implementation checks fully enforced, >>with an E_COMPILE_ERROR emitted in case of an error. > >Excuse my ignorance: What is defined as fully implementing the interface? >I guess all methods have to be implemented with all the parameters having >the same type if specified, right? What about extending the parameter set, >especially with default values? >E.g. is foo(A $a, $newparam = 'false) valid for foo(A $a)?
This is valid. As long as you *can* call the function using the same prototype as the one in the interface, it's considered to be compatible. You can extend it using default values. Zeev

Jan Schneider

22 years ago
Zitat von Zeev Suraski <zeev@zend.com>:
> At 13:01 19/04/2004, Christian Schneider wrote: >> Zeev Suraski wrote: >>> Any method that implements (directly or indirectly) an interface >>> method or an abstract method, will have implementation checks fully >>> enforced, with an E_COMPILE_ERROR emitted in case of an error. >> >> Excuse my ignorance: What is defined as fully implementing the >> interface? I guess all methods have to be implemented with all the >> parameters having the same type if specified, right? What about >> extending the parameter set, especially with default values? >> E.g. is foo(A $a, $newparam = 'false) valid for foo(A $a)? > > This is valid. As long as you *can* call the function using the same > prototype as the one in the interface, it's considered to be > compatible. You can extend it using default values.
+1 from a user's perspective, that is pro fatal errors on interfaces and abstract methods but not on regular methods. That's the best balance on keeping BC and introducing useful OO features. Jan.
-- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft

Zeev Suraski

22 years ago
At 13:04 19/04/2004, Andi Gutmans wrote:
>Hey, > >I just wanted to note the fact that I disagree with this. >In a perfect world, I would go with an E_COMPILE_ERROR in all situations; >when inheriting regular classes (w/o abstract methods), abstract methods >and interfaces. That is what the academic part of me feels but knows can't >be done. >As this would break BC too much, I agree that inheriting from regular >classes should not lead to an error. I believe that for consistency sake >interfaces and abstract classes should behave the same as regular classes, >thus, if regular classes don't cause an error, the former also shouldn't.
Just to clarify a bit on why I think that we should differentiate: 1. First of all, I agree that in a perfect world we should go with E_COMPILE_ERROR for everything. Maybe now that's constructors are out of the picture, people will be more receptive to the idea - if we can go down that route, that option clearly gets my vote. 2. If going for E_COMPILE_ERROR in all situations is not an option, then I do see a significant difference between interface/abstract methods, and real methods, when it comes to inheriting from them. The whole interface/abstract/class type hints mechanism was added for the sole reason of enforcing prototypes, and effectively, it is pretty much useless the way things are now. If we re-enable fatal errors for interface inheritance - we give OO programmers the ability to enforce prototypes. They would have to use an interface (or an abstract class) in order to do so, since it won't be enforced for just plain classes - but at least they'd have this option. To make it clear, my vote still goes for option #1, if people feel better about it now... Zeev

Christian Schneider

22 years ago
Zeev Suraski wrote:
> 1. First of all, I agree that in a perfect world we should go with > E_COMPILE_ERROR for everything. Maybe now that's constructors are out
I'm not sure I understand what you mean by everything.
> whole interface/abstract/class type hints mechanism was added for the > sole reason of enforcing prototypes, and effectively, it is pretty much
Concerning interface/abstract classes I can see you reasoning for enforcing the prototype. Personally I don't feel like using interfaces and abstract classes but as it is implemented in PHP5 it should be done right. Make whips and chains people suffer fully from their bondage addiction :-) For class type hints (this is specifying the parameter type in your function definition, right?) I think it should be enforced for *calling* but not for extending. A specialized class often leaves out parameters of the generic base class. E.g. db_record_foo may extend db_record which takes the table as an argument which will always be foo for the specialized class and hence left out there. Does that make sense? - Chris

Zeev Suraski

22 years ago
At 13:28 19/04/2004, Christian Schneider wrote:
>Zeev Suraski wrote: >>1. First of all, I agree that in a perfect world we should go with >>E_COMPILE_ERROR for everything. Maybe now that's constructors are out > >I'm not sure I understand what you mean by everything.
Everything means for both overriding a method and implementing an interface/abstract method.
>>whole interface/abstract/class type hints mechanism was added for the >>sole reason of enforcing prototypes, and effectively, it is pretty much > >Concerning interface/abstract classes I can see you reasoning for >enforcing the prototype. Personally I don't feel like using interfaces and >abstract classes but as it is implemented in PHP5 it should be done right. >Make whips and chains people suffer fully from their bondage addiction :-) > >For class type hints (this is specifying the parameter type in your >function definition, right?) I think it should be enforced for *calling* >but not for extending. A specialized class often leaves out parameters of >the generic base class. E.g. db_record_foo may extend db_record which >takes the table as an argument which will always be foo for the >specialized class and hence left out there. > >Does that make sense?
In my opinion it doesn't, because it breaks the interface of the parent class. I.e., you can no longer use code you've written to work with an object of the parent class, with an object of the child class, which breaks one of the most fundamental principals of OO. In turn, it renders class type hints useless, because the fact that you have an object of type Foo gives you very little - you have no idea what its interface is, because Bar, derived from Foo, can have a completely different interface. What I'm asking is that, short of enabling these checks for everything (as defined above) due to significant opposition, we should at least re-enable them for interface/abstract methods (this was the way things were for about half a year, until the previous discussion about this subject a couple of months back). That way we give true OO developers the ability to enforce prototypes, without breaking old code. Zeev

Christian Schneider

22 years ago
Zeev Suraski wrote:
> In my opinion it doesn't, because it breaks the interface of the parent > class. I.e., you can no longer use code you've written to work with an > object of the parent class, with an object of the child class, which > breaks one of the most fundamental principals of OO. In turn, it
What about the generic/specialized class example? At least the constructor has to be allowed to be different, no? Or was that what you meant by "Maybe now that's constructors are out of the picture"?
> re-enable them for interface/abstract methods (this was the way things > were for about half a year, until the previous discussion about this > subject a couple of months back). That way we give true OO developers > the ability to enforce prototypes, without breaking old code.
I have no problem with this behaviour for interface/abstract methods. - Chris

Zeev Suraski

22 years ago
At 14:40 19/04/2004, Christian Schneider wrote:
>Zeev Suraski wrote: >>In my opinion it doesn't, because it breaks the interface of the parent >>class. I.e., you can no longer use code you've written to work with an >>object of the parent class, with an object of the child class, which >>breaks one of the most fundamental principals of OO. In turn, it > >What about the generic/specialized class example? At least the constructor >has to be allowed to be different, no? Or was that what you meant by >"Maybe now that's constructors are out of the picture"?
That's exactly what I meant, constructors don't have implementation checks any longer... If we can agree that for everything else we can apply these rules, including regular methods, it's a big step :) Zeev

Derick Rethans

22 years ago
On Mon, 19 Apr 2004, Zeev Suraski wrote:
> At 14:40 19/04/2004, Christian Schneider wrote: > >Zeev Suraski wrote: > >>In my opinion it doesn't, because it breaks the interface of the parent > >>class. I.e., you can no longer use code you've written to work with an > >>object of the parent class, with an object of the child class, which > >>breaks one of the most fundamental principals of OO. In turn, it > > > >What about the generic/specialized class example? At least the constructor > >has to be allowed to be different, no? Or was that what you meant by > >"Maybe now that's constructors are out of the picture"? > > That's exactly what I meant, constructors don't have implementation checks > any longer... > If we can agree that for everything else we can apply these rules, > including regular methods, it's a big step :)
I don't want it for regular methods, it's going to break BC. I can live with anything, as long as it doesn't break PHP 4 code (not even with E_STRICT on). regards, Derick

Shane Caraveo

22 years ago
Zeev Suraski wrote:
> At 13:28 19/04/2004, Christian Schneider wrote: > >> Zeev Suraski wrote: >> >>> 1. First of all, I agree that in a perfect world we should go with >>> E_COMPILE_ERROR for everything. Maybe now that's constructors are out >> >> >> I'm not sure I understand what you mean by everything. > > > Everything means for both overriding a method and implementing an > interface/abstract method.
> In my opinion it doesn't, because it breaks the interface of the parent > class. I.e., you can no longer use code you've written to work with an > object of the parent class, with an object of the child class, which > breaks one of the most fundamental principals of OO. In turn, it > renders class type hints useless, because the fact that you have an > object of type Foo gives you very little - you have no idea what its > interface is, because Bar, derived from Foo, can have a completely > different interface.
I think using a compile error for interface/abstract class issues is a *very* good thing, but turning inheritance into an interface is not. If someone wants to know that a particular class instance has a predefined interface, use an interface. Shane

Hans Lellelid

22 years ago
Hi, Zeev Suraski wrote:
> > What I'm asking is that, short of enabling these checks for everything > (as defined above) due to significant opposition, we should at least > re-enable them for interface/abstract methods (this was the way things > were for about half a year, until the previous discussion about this > subject a couple of months back). That way we give true OO developers > the ability to enforce prototypes, without breaking old code. > > Zeev
I wanted to chime in since I'm one of the people who was strongly against E_COMPILE_ERROR for *regular* class inheritance. I still feel strongly about that because it breaks tons of code out there. If PHP can't support method overloading, then I think it it needs to allow method *overriding* in order to meet the needs of userland developers like myself. However ... I definitely think that method signatures should be checked and enforced for interfaces and abstract classes. I think at one point, when faced with broken PHP5 code after an update to one of the late betas, I suggested allowing interfaces to override parent (i.e. other interface) methods to be consistent with classes. I can live (and am living) without this "feature", though. As a userland PHP5 developer, I vote a strong +1 for more strict interfaces. I was saddened to see those become impotent (i.e. E_STRICT) as a result of the last discussion (which I thought was simply an opposition to doing the E_COMPILE_ERROR accross the board w/ classes). Anyway, of course consistency also counts for something :) Hans

Marcus Börger

22 years ago
Hello Zeev, Monday, April 19, 2004, 12:14:40 PM, you wrote:
> At 13:04 19/04/2004, Andi Gutmans wrote: >>Hey, >> >>I just wanted to note the fact that I disagree with this. >>In a perfect world, I would go with an E_COMPILE_ERROR in all situations; >>when inheriting regular classes (w/o abstract methods), abstract methods >>and interfaces. That is what the academic part of me feels but knows can't >>be done. >>As this would break BC too much, I agree that inheriting from regular >>classes should not lead to an error. I believe that for consistency sake >>interfaces and abstract classes should behave the same as regular classes, >>thus, if regular classes don't cause an error, the former also shouldn't.
> Just to clarify a bit on why I think that we should differentiate: > 1. First of all, I agree that in a perfect world we should go with > E_COMPILE_ERROR for everything. Maybe now that's constructors are out of > the picture, people will be more receptive to the idea - if we can go down > that route, that option clearly gets my vote. > 2. If going for E_COMPILE_ERROR in all situations is not an option, then I > do see a significant difference between interface/abstract methods, and > real methods, when it comes to inheriting from them. The whole > interface/abstract/class type hints mechanism was added for the sole reason > of enforcing prototypes, and effectively, it is pretty much useless the way > things are now.
repeat useless.
> If we re-enable fatal errors for interface inheritance - > we give OO programmers the ability to enforce prototypes. They would have > to use an interface (or an abstract class) in order to do so, since it > won't be enforced for just plain classes - but at least they'd have this > option.
> To make it clear, my vote still goes for option #1, if people feel better > about it now...
fellBetter++ Doesn't this bring us back to the option to couple the severity for 'normal' methods (no interface/abstract/typehints btw easily detecable by a new fn_flag) with the ini setting for the engine's bc mode? Best regards, Marcus mailto:helly@php.net

George Schlossnagle

22 years ago
On Apr 19, 2004, at 2:49 PM, Marcus Boerger wrote:
> Hello Zeev, > > Monday, April 19, 2004, 12:14:40 PM, you wrote: > >> At 13:04 19/04/2004, Andi Gutmans wrote: >>> Hey, >>> >>> I just wanted to note the fact that I disagree with this. >>> In a perfect world, I would go with an E_COMPILE_ERROR in all >>> situations; >>> when inheriting regular classes (w/o abstract methods), abstract >>> methods >>> and interfaces. That is what the academic part of me feels but knows >>> can't >>> be done. >>> As this would break BC too much, I agree that inheriting from regular >>> classes should not lead to an error. I believe that for consistency >>> sake >>> interfaces and abstract classes should behave the same as regular >>> classes, >>> thus, if regular classes don't cause an error, the former also >>> shouldn't. > >> Just to clarify a bit on why I think that we should differentiate: >> 1. First of all, I agree that in a perfect world we should go with >> E_COMPILE_ERROR for everything. Maybe now that's constructors are >> out of >> the picture, people will be more receptive to the idea - if we can go >> down >> that route, that option clearly gets my vote.
+1
>> 2. If going for E_COMPILE_ERROR in all situations is not an option, >> then I >> do see a significant difference between interface/abstract methods, >> and >> real methods, when it comes to inheriting from them. The whole >> interface/abstract/class type hints mechanism was added for the sole >> reason >> of enforcing prototypes, and effectively, it is pretty much useless >> the way >> things are now. > > repeat useless.
yep.
>> To make it clear, my vote still goes for option #1, if people feel >> better >> about it now... > > fellBetter++
I also think this is the way to go. George

Christian Schneider

22 years ago
George Schlossnagle wrote:
>>> Just to clarify a bit on why I think that we should differentiate: >>> 1. First of all, I agree that in a perfect world we should go with >>> E_COMPILE_ERROR for everything. Maybe now that's constructors are > > +1
Are you guys serious about a compile error if I override a method with different parameters? This must be the mailing list of a different language than PHP... - Chris

George Schlossnagle

22 years ago
On Apr 19, 2004, at 5:37 PM, Christian Schneider wrote:
> George Schlossnagle wrote: >>>> Just to clarify a bit on why I think that we should differentiate: >>>> 1. First of all, I agree that in a perfect world we should go with >>>> E_COMPILE_ERROR for everything. Maybe now that's constructors are >> +1 > > Are you guys serious about a compile error if I override a method with > different parameters? This must be the mailing list of a different > language than PHP...
If you override an interface with a different number of parameters or with incorrectly typed parameters, yes. George

George Schlossnagle

22 years ago
On Apr 19, 2004, at 5:45 PM, George Schlossnagle wrote:
> > On Apr 19, 2004, at 5:37 PM, Christian Schneider wrote: > >> George Schlossnagle wrote: >>>>> Just to clarify a bit on why I think that we should differentiate: >>>>> 1. First of all, I agree that in a perfect world we should go with >>>>> E_COMPILE_ERROR for everything. Maybe now that's constructors are >>> +1 >> >> Are you guys serious about a compile error if I override a method >> with different parameters? This must be the mailing list of a >> different language than PHP... > > If you override an interface with a different number of parameters or > with incorrectly typed parameters, yes.
^^^^^^^ make that read 'implement', of course. George

Christian Schneider

22 years ago
George Schlossnagle wrote:
>>>>> 1. First of all, I agree that in a perfect world we should go with >>>>> E_COMPILE_ERROR for everything. Maybe now that's constructors are >>> >>> +1 >> >> Are you guys serious about a compile error if I override a method with >> different parameters? This must be the mailing list of a different >> language than PHP... > > If you override an interface with a different number of parameters or > with incorrectly typed parameters, yes.
I agree there but 1. was saying _everything_, that included more than just interfaces and abstract classes. That's why I'm asking if you're serious. Let's recap: a) People agree to be strict for *interfaces* and *abstract classes*. b) There was a proposal to also give a compile error for normal methods. I'm not sure if people who gave a +1 here really meant it. - Chris

Sterling Hughes

22 years ago
It is. This is a mailing list discussing for discussing the use of exceptions and compile errors in java. If you are not interested in that, please unsubscribe. -Sterling On Apr 19, 2004, at 2:37 PM, Christian Schneider wrote:

Sterling Hughes

22 years ago
mo compile errors mo better. +1. -Sterling On Apr 19, 2004, at 12:52 PM, George Schlossnagle wrote:

Derick Rethans

22 years ago
On Mon, 19 Apr 2004, Sterling Hughes wrote:
> mo compile errors mo better.
But NOT for normal methods! Derick

George Schlossnagle

22 years ago
On Apr 20, 2004, at 3:22 AM, Derick Rethans wrote:
> On Mon, 19 Apr 2004, Sterling Hughes wrote: > >> mo compile errors mo better. > > But NOT for normal methods!
I agree with Derick. Compile errors for interfaces methods good. Compile errors for normal inherited methods bad.
> > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
// George Schlossnagle // Postal Engine -- http://www.postalengine.com/ // Ecelerity: fastest MTA on earth

Adam Maccabee Trachtenberg

22 years ago
On Tue, 20 Apr 2004, George Schlossnagle wrote:
> On Apr 20, 2004, at 3:22 AM, Derick Rethans wrote: > > > On Mon, 19 Apr 2004, Sterling Hughes wrote: > > > >> mo compile errors mo better. > > > > But NOT for normal methods! > > I agree with Derick. Compile errors for interfaces methods good. > Compile errors for normal inherited methods bad.
Amen! While I'm in favor of this for other reasons, my largest argument is backwards compatibility. Compile errors for normal methods is guaranteed to break *lots* of PHP 4 code and not in a trivial s/var/public/g kind of way. -adam
-- adam@trachtenberg.com author of o'reilly's php cookbook avoid the holiday rush, buy your copy today!

Magnus Maatta

22 years ago
On Monday 19 April 2004 10.49, Zeev Suraski wrote:
> Suggested behavior: > Any method that implements (directly or indirectly) an interface method or > an abstract method, will have implementation checks fully enforced, with an > E_COMPILE_ERROR emitted in case of an error. > Behavior for methods that override regular parent methods, that do not have > interface/abstract prototypes, will not change (E_STRICT message). > > Comments welcome - we'd like to sort this out before RC2...
I couldn't agree more (since I'm the one who "complained" =) This can be very frustrating.. /Magnus
-- BOFH Excuse #412: Radial Telemetry Infiltration

Ferdinand Beyer

22 years ago
On 19 Apr 2004 at 11:49, Zeev Suraski wrote:
> Suggested behavior: > Any method that implements (directly or indirectly) an interface
method or
> an abstract method, will have implementation checks fully
enforced, with an
> E_COMPILE_ERROR emitted in case of an error. > Behavior for methods that override regular parent methods, that do
not have
> interface/abstract prototypes, will not change (E_STRICT
message).
> > Comments welcome - we'd like to sort this out before RC2...
I don't like the idea as it does not allow var args to emulate overloaded methods. I repeat myself when I say that IMO such strictness does not fit to PHP's loose character.
-- Ferdinand Beyer <fb@fbeyer.com>

Magnus Maatta

22 years ago
On Monday 19 April 2004 16.10, Ferdinand Beyer wrote:
> > > Comments welcome - we'd like to sort this out before RC2... > > I don't like the idea as it does not allow var args to emulate > overloaded methods. I repeat myself when I say that IMO such > strictness does not fit to PHP's loose character.
If you don't want strictness, don't use interfaces. If this doesn't get changed I might aswell change all my code to not use them at all since they would be pretty much useless. /Magnus
-- Where will it all end? Probably somewhere near where it all began.

Christian Schneider

22 years ago
Magnus Määttä wrote:
> If you don't want strictness, don't use interfaces. If this doesn't get
I agree. Which also means that the PHP core and extensions should be written without interfaces to avoid forcing people to use them. Otherwise you end up with an extension you can't use with another framework using __call() (e.g. SOAP) or varargs. I hope PHP will be kept free of the Sortable, Enumerable, etc. interface hordes common in other languages. PINJ (PHP Is Not Java), - Chris

Marcus Börger

22 years ago
Hello Ferdinand, Monday, April 19, 2004, 4:10:29 PM, you wrote:
> On 19 Apr 2004 at 11:49, Zeev Suraski wrote:
>> Suggested behavior: >> Any method that implements (directly or indirectly) an interface > method or >> an abstract method, will have implementation checks fully > enforced, with an >> E_COMPILE_ERROR emitted in case of an error. >> Behavior for methods that override regular parent methods, that do > not have >> interface/abstract prototypes, will not change (E_STRICT > message). >> >> Comments welcome - we'd like to sort this out before RC2...
> I don't like the idea as it does not allow var args to emulate > overloaded methods. I repeat myself when I say that IMO such > strictness does not fit to PHP's loose character.
Simply decalre thos methos with an empty signature and use the appropriate functions to handle the arguments? marcus
-- Best regards, Marcus mailto:helly@php.net

Ferdinand Beyer

22 years ago
On 19 Apr 2004 at 20:44, Marcus Boerger wrote:
> Simply decalre thos methos with an empty signature and use the > appropriate functions to handle the arguments?
That does not work for foreign/internal interfaces/base classes. Again: Why should we add this strictness? Since PHP is loosely typed, you can't guarantee that a class is implementing an interface correctly even if the method accepts the same number of arguments... I am NOT saying that Interfaces are useless (or would be without strict arguments checking). What about this case: interface A { public function doSomething($integer1, $integer2); } interface B { public function doSomething(MyObject $obj); } class Impl implements A, B { // "Overloaded" - supports both doSomething() interfaces public function doSomething() { // Use var_args to distinquish the two doSomething()'s } }
-- Ferdinand Beyer <fb@fbeyer.com>

Stanislav Malyshev

22 years ago
FB>>interface A { FB>> public function doSomething($integer1, $integer2); FB>>} FB>> FB>>interface B { FB>> public function doSomething(MyObject $obj); FB>>} FB>> FB>>class Impl implements A, B FB>>{ FB>> // "Overloaded" - supports both doSomething() interfaces FB>> public function doSomething() FB>> { FB>> // Use var_args to distinquish the two doSomething()'s FB>> } FB>>} The problem here that you can't know if Impl would actually accept MyObject or two integers as arguments. So if some method requires object with interface A and it's passed Impl, it cannot actually be sure it can use it as an A object.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Ferdinand Beyer

22 years ago
On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote:
> FB>>interface A { > FB>> public function doSomething($integer1, $integer2); > FB>>} > FB>> > FB>>interface B { > FB>> public function doSomething(MyObject $obj); > FB>>} > FB>> > FB>>class Impl implements A, B > FB>>{ > FB>> // "Overloaded" - supports both doSomething() interfaces > FB>> public function doSomething() > FB>> { > FB>> // Use var_args to distinquish the two doSomething()'s > FB>> } > FB>>} > > The problem here that you can't know if Impl would actually accept > MyObject or two integers as arguments. So if some method
requires object
> with interface A and it's passed Impl, it cannot actually be sure it
can
> use it as an A object.
Impl guarantees that by implementing interface A. What if Impl::doSomething() would accept exactly two parameters, but expects them to be arrays? IMO you cannot enforce this strictness with loose types...
-- Ferdinand Beyer <fb@fbeyer.com>

George Schlossnagle

22 years ago
On Apr 20, 2004, at 10:48 AM, Ferdinand Beyer wrote:
> On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote: > >> FB>>interface A { >> FB>> public function doSomething($integer1, $integer2); >> FB>>} >> FB>> >> FB>>interface B { >> FB>> public function doSomething(MyObject $obj); >> FB>>} >> FB>> >> FB>>class Impl implements A, B >> FB>>{ >> FB>> // "Overloaded" - supports both doSomething() interfaces >> FB>> public function doSomething() >> FB>> { >> FB>> // Use var_args to distinquish the two doSomething()'s >> FB>> } >> FB>>} >> >> The problem here that you can't know if Impl would actually accept >> MyObject or two integers as arguments. So if some method > requires object >> with interface A and it's passed Impl, it cannot actually be sure it > can >> use it as an A object. > > Impl guarantees that by implementing interface A. > > What if Impl::doSomething() would accept exactly two parameters, > but expects them to be arrays? > > IMO you cannot enforce this strictness with loose types...
This is probably a bad argument since while PHP doesn't currently allow type hinting based on whether a parameter is an array vs. a scalar, it's technically feasible and their is no good auto-casting from array to scalar or vice-versa. A better argument is expecting different types of scalars. That would be much harder with PHP's typing semantic. George

Stanislav Malyshev

22 years ago
FB>>Impl guarantees that by implementing interface A. No. It _says_ it implements interface A, but you couldn't know if it indeed does, if we allow your model - maybe that "dispatched" function call doesn't really accept those arguments? FB>>What if Impl::doSomething() would accept exactly two parameters, but FB>>expects them to be arrays? Then how can you say it implements B where object is required? Since PHP does not dispatch methods by parameters, I don't know if there's a good way to implement both A and B interfaces except making all doSomething definitions not accept parameters or give them different names. FB>>IMO you cannot enforce this strictness with loose types... When you use interfaces and typehints, you give up the loose-typedness, not? You say "here the types can't be loose - I want exactly this class and nothing else in this parameter".
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Ferdinand Beyer

22 years ago
On 20 Apr 2004 at 17:55, Stanislav Malyshev wrote:
> FB>>Impl guarantees that by implementing interface A. > > No. It _says_ it implements interface A, but you couldn't know if it > indeed does, if we allow your model - maybe that "dispatched"
function
> call doesn't really accept those arguments?
interface I { /** Documentation says: $a is an integer, $b is a string */ function doSomething($a, $b); } class C implements I { function doSomething($a, $b) { } } We still can't be sure if C::doSometing() actually accepts an integer and a string. We have to trust C. So we can also trust Impl from the previous example...
> FB>>What if Impl::doSomething() would accept exactly two
parameters, but
> FB>>expects them to be arrays? > > Then how can you say it implements B where object is required?
I meant to change Impl to accept arrays and to drop the B implementation.
> Since PHP does not dispatch methods by parameters, I don't know
if there's
> a good way to implement both A and B interfaces except making
all
> doSomething definitions not accept parameters or give them
different
> names.
Provided that one has access to the interfaces...
-- Ferdinand Beyer <fb@fbeyer.com>

George Schlossnagle

22 years ago
On Apr 20, 2004, at 11:14 AM, Ferdinand Beyer wrote:
> On 20 Apr 2004 at 17:55, Stanislav Malyshev wrote: > >> FB>>Impl guarantees that by implementing interface A. >> >> No. It _says_ it implements interface A, but you couldn't know if it >> indeed does, if we allow your model - maybe that "dispatched" > function >> call doesn't really accept those arguments? > > interface I { > /** Documentation says: $a is an integer, $b is a string */ > function doSomething($a, $b); > } > > class C implements I > { > function doSomething($a, $b) > { > } > } > > We still can't be sure if C::doSometing() actually accepts an integer > and a string. We have to trust C. So we can also trust Impl from the > previous example...
PHP doesn't support this, regardless of you being able to tell them apart, scalar types in PHP are isomorphic.
>> Since PHP does not dispatch methods by parameters, I don't know > if there's >> a good way to implement both A and B interfaces except making > all >> doSomething definitions not accept parameters or give them > different >> names. > > Provided that one has access to the interfaces...
I must not understand this comment. How can you implement an interface you don't have knowledge of? The fact is that since PHP doesn't support parameter based method dispatching, you _can't_ implement both A and B, since you can not comply with both signature contracts simultaneously. George

Ferdinand Beyer

22 years ago
On 20 Apr 2004 at 11:22, George Schlossnagle wrote:
> PHP doesn't support this, regardless of you being able to tell them > apart, scalar types in PHP are isomorphic.
Yes, I know. This is why I am against strict parameter checking.
> > Provided that one has access to the interfaces... > > I must not understand this comment. How can you implement an
interface
> you don't have knowledge of?
I meant in some cases you cannot change the underlying interface or base class. Classes in third-party libraries or internal classes, for example.
> The fact is that since PHP doesn't support parameter based
method
> dispatching, you _can't_ implement both A and B, since you can
not
> comply with both signature contracts simultaneously.
IMO I should, using variable arguments. This is currently impossible.
-- Ferdinand Beyer <fb@fbeyer.com>

George Schlossnagle

22 years ago
On Apr 20, 2004, at 11:39 AM, Ferdinand Beyer wrote:
> On 20 Apr 2004 at 11:22, George Schlossnagle wrote: > >> PHP doesn't support this, regardless of you being able to tell them >> apart, scalar types in PHP are isomorphic. > > Yes, I know. This is why I am against strict parameter checking.
Everything works fine if you except that 'scalar' is a base type and that int, string, etc. are not.
>>> Provided that one has access to the interfaces... >> >> I must not understand this comment. How can you implement an > interface >> you don't have knowledge of? > > I meant in some cases you cannot change the underlying interface > or base class. Classes in third-party libraries or internal classes, > for > example.
If you need to change the interface then you shouldnt be implementing it.
> >> The fact is that since PHP doesn't support parameter based > method >> dispatching, you _can't_ implement both A and B, since you can > not >> comply with both signature contracts simultaneously. > > IMO I should, using variable arguments. This is currently impossible.
Then you aren't implementing the interface. The interface is a contract, you can't enforce it with variable arguments. George

Sterling Hughes

22 years ago
I agree. Interfaces are useless if you can't guarantee that a class actually implements them. Violating an interface is violating a contract and it should be an compile error - indeed, when coding I mostly rely on not properly implementing interfaces to be a compile error. -Sterling -----Original Message----- From: Zeev Suraski [mailto:zeev@zend.com] Sent: Monday, April 19, 2004 1:49 AM To: internals@lists.php.net Subject: [PHP-DEV] Interface inheritance All, Yesterday, someone complained that classes that implement interfaces succeed in doing so even when they don't satisfy the prototypes. While this does cause an E_STRICT message to be emitted, it would go unnoticed in most cases, as E_STRICT is off by default, in some cases - even when people think it's on. I believe that this behavior is wrong. I believe that classes should not be allowed to say they implement an interface X, unless they actually implement all of the methods in that interface with methods that are compatible with its prototypes. Reasoning: - Interfaces (and for that matter, abstract classes) are a new feature in PHP 5, used solely to enforce implementing classes to abide to the prototypes. There's no issue of downwards compatibility, and there's no other use case. - Without this, the whole mechanism of class type hints is rendered useless. With it, it gives users the full power of class type hints (and instanceof, for that matter) - because they always have the option of adding an interface for their base classes. Suggested behavior: Any method that implements (directly or indirectly) an interface method or an abstract method, will have implementation checks fully enforced, with an E_COMPILE_ERROR emitted in case of an error. Behavior for methods that override regular parent methods, that do not have interface/abstract prototypes, will not change (E_STRICT message). Comments welcome - we'd like to sort this out before RC2... Zeev
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Andi Gutmans

22 years ago
Yes, but I claim that inheritance is exactly the same thing. I comes with an interface which needs to be adhered to. It does tend to be inconsistent if we E_ERROR out on interfaces and not on inheritance. At 09:31 AM 4/19/2004 -0700, Sterling Hughes wrote:

Alan Knowles

22 years ago
I would prefer <speak evil>an ini option</speak evil>, while on a development or testing server interfaces are great, I would love to be able to reduce this to a E_NOTICE on a live server, and stuff it in an error log... Regards Alan Zeev Suraski wrote:
> All, > > Yesterday, someone complained that classes that implement interfaces > succeed in doing so even when they don't satisfy the prototypes. While > this does cause an E_STRICT message to be emitted, it would go unnoticed > in most cases, as E_STRICT is off by default, in some cases - even when > people think it's on. > > I believe that this behavior is wrong. I believe that classes should > not be allowed to say they implement an interface X, unless they > actually implement all of the methods in that interface with methods > that are compatible with its prototypes. > > Reasoning: > - Interfaces (and for that matter, abstract classes) are a new feature > in PHP 5, used solely to enforce implementing classes to abide to the > prototypes. There's no issue of downwards compatibility, and there's no > other use case. > - Without this, the whole mechanism of class type hints is rendered > useless. With it, it gives users the full power of class type hints > (and instanceof, for that matter) - because they always have the option > of adding an interface for their base classes. > > Suggested behavior: > Any method that implements (directly or indirectly) an interface method > or an abstract method, will have implementation checks fully enforced, > with an E_COMPILE_ERROR emitted in case of an error. > Behavior for methods that override regular parent methods, that do not > have interface/abstract prototypes, will not change (E_STRICT message). > > Comments welcome - we'd like to sort this out before RC2... > > Zeev >
-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com

Stanislav Malyshev

22 years ago
ZS>>I believe that this behavior is wrong. I believe that classes should ZS>>not be allowed to say they implement an interface X, unless they ZS>>actually implement all of the methods in that interface with methods ZS>>that are compatible with its prototypes. I agree. Since interfaces and abstract classes are new to PHP5, and do not pose compatibility problem, I think it's good to make them strict. The old behaviour can be always obtained by using regular classes.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115