Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- [EMAIL PROTECTED] author of o'reilly's php cookbook avoid the holiday rush, buy your copy today! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
On Mon, 19 Apr 2004, Sterling Hughes wrote: > mo compile errors mo better. But NOT for normal methods! Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
mo compile errors mo better. +1. -Sterling On Apr 19, 2004, at 12:52 PM, George Schlossnagle wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Interface inheritance
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: 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:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 1:49 AM To: [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Interface inheritance
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:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 1:49 AM To: [EMAIL PROTECTED] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
And regular old-style inheritance? At 12:45 PM 4/19/2004 +0200, Sebastian Bergmann wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
For interfaces and abstract methods? At 12:17 PM 4/19/2004 +0200, Sebastian Bergmann wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interface inheritance
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php