# Interface inheritance - Thread: https://externals.io/message/9362 - Original archive: https://news-web.php.net/php.internals/9362 - Started by Zeev Suraski on 2004-04-19T08:49:04+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/9362.md?page=2 - 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 --- ## #9362 — Zeev Suraski — 2004-04-19T08:49:04+00:00 URL: https://externals.io/message/9362#9362 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 --- ## #9363 — Derick Rethans — 2004-04-19T09:06:41+00:00 URL: https://externals.io/message/9362#9363 · In reply to: #9362 > 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 --- ## #9364 — Christian Schneider — 2004-04-19T10:01:16+00:00 URL: https://externals.io/message/9362#9364 · In reply to: #9362 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 --- ## #9365 — Andi Gutmans — 2004-04-19T10:04:18+00:00 URL: https://externals.io/message/9362#9365 · In reply to: #9362 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: >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 --- ## #9366 — Zeev Suraski — 2004-04-19T10:04:30+00:00 URL: https://externals.io/message/9362#9366 · In reply to: #9362 At 13:01 19/04/2004, Christian Schneider wrote: >Zeev Suraski wrote: > > […] > >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 --- ## #9367 — Zeev Suraski — 2004-04-19T10:14:40+00:00 URL: https://externals.io/message/9362#9367 · In reply to: #9362 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 --- ## #9368 — Sebastian Bergmann — 2004-04-19T10:17:39+00:00 URL: https://externals.io/message/9362#9368 · In reply to: #9365 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/ --- ## #9370 — Christian Schneider — 2004-04-19T10:28:51+00:00 URL: https://externals.io/message/9362#9370 · In reply to: #9367 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 --- ## #9376 — magnus@php.net — 2004-04-19T11:02:13+00:00 URL: https://externals.io/message/9362#9376 · In reply to: #9362 > 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 --- ## #9381 — Jan Schneider — 2004-04-19T12:39:02+00:00 URL: https://externals.io/message/9362#9381 · In reply to: #9366 Zitat von Zeev Suraski : > At 13:01 19/04/2004, Christian Schneider wrote: > > […] > > 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 --- ## #9382 — Ferdinand Beyer — 2004-04-19T14:10:29+00:00 URL: https://externals.io/message/9362#9382 · In reply to: #9362 > 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 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 --- ## #9390 — Marcus Boerger — 2004-04-19T18:44:23+00:00 URL: https://externals.io/message/9362#9390 · In reply to: #9382 Hello Ferdinand, Monday, April 19, 2004, 4:10:29 PM, you wrote: > > > […] > method or > > […] > enforced, with an > > […] > not have > > […] > message). > > […] > 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 --- ## #9391 — Marcus Boerger — 2004-04-19T18:49:33+00:00 URL: https://externals.io/message/9362#9391 · In reply to: #9367 Hello Zeev, Monday, April 19, 2004, 12:14:40 PM, you wrote: > At 13:04 19/04/2004, Andi Gutmans 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 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 --- ## #9396 — George Schlossnagle — 2004-04-19T19:52:15+00:00 URL: https://externals.io/message/9362#9396 · In reply to: #9391 > Hello Zeev, > > Monday, April 19, 2004, 12:14:40 PM, you wrote: > > > […] > > > […] +1 > > […] > > repeat useless. yep. > > […] > > fellBetter++ I also think this is the way to go. George --- ## #9400 — Christian Schneider — 2004-04-19T21:37:12+00:00 URL: https://externals.io/message/9362#9400 · In reply to: #9396 George Schlossnagle wrote: > > […] > > +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 --- ## #9401 — George Schlossnagle — 2004-04-19T21:45:49+00:00 URL: https://externals.io/message/9362#9401 · In reply to: #9400 > George Schlossnagle wrote: > > […] > > 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 --- ## #9402 — George Schlossnagle — 2004-04-19T21:46:49+00:00 URL: https://externals.io/message/9362#9402 · In reply to: #9401 > > > > > […] > > If you override an interface with a different number of parameters or > with incorrectly typed parameters, yes. ^^^^^^^ make that read 'implement', of course. George --- ## #9403 — Christian Schneider — 2004-04-19T21:48:39+00:00 URL: https://externals.io/message/9362#9403 · In reply to: #9401 George Schlossnagle wrote: > > […] > > 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 --- ## #9404 — Sterling Hughes — 2004-04-19T22:42:51+00:00 URL: https://externals.io/message/9362#9404 · In reply to: #9396 mo compile errors mo better. +1. -Sterling > > > > > […] > > +1 > > > […] > > yep. > > > […] > > I also think this is the way to go. > > George --- ## #9405 — Sterling Hughes — 2004-04-19T23:54:12+00:00 URL: https://externals.io/message/9362#9405 · In reply to: #9400 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 > George Schlossnagle wrote: > > […] > > 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 --- ## #9407 — Alan Knowles — 2004-04-20T01:34:04+00:00 URL: https://externals.io/message/9362#9407 · In reply to: #9362 I would prefer an ini option, 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 --- ## #9409 — Derick Rethans — 2004-04-20T07:22:20+00:00 URL: https://externals.io/message/9362#9409 · In reply to: #9404 > mo compile errors mo better. But NOT for normal methods! Derick --- ## #9415 — Stanislav Malyshev — 2004-04-20T12:30:18+00:00 URL: https://externals.io/message/9362#9415 · In reply to: #9362 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 --- Next page: https://externals.io/message/9362.md?page=2