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
ZSI believe that this behavior is wrong. I believe that classes should ZSnot be allowed to say they implement an interface X, unless they ZSactually implement all of the methods in that interface with methods ZSthat 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 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
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 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
FBinterface A {
FBpublic function doSomething($integer1, $integer2);
FB}
FB
FBinterface B {
FB public function doSomething(MyObject $obj);
FB}
FB
FBclass Impl implements A, B
FB{
FB// Overloaded - supports both doSomething() interfaces
FBpublic 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
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
On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote:
FBinterface A {
FBpublic function doSomething($integer1, $integer2);
FB}
FB
FBinterface B {
FB public function doSomething(MyObject $obj);
FB}
FB
FBclass Impl implements A, B
FB{
FB// Overloaded - supports both doSomething() interfaces
FBpublic 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
On Apr 20, 2004, at 10:48 AM, Ferdinand Beyer wrote:
On 20 Apr 2004 at 17:38, Stanislav Malyshev wrote:
FBinterface A {
FBpublic function doSomething($integer1, $integer2);
FB}
FB
FBinterface B {
FB public function doSomething(MyObject $obj);
FB}
FB
FBclass Impl implements A, B
FB{
FB// Overloaded - supports both doSomething() interfaces
FBpublic 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
FBImpl 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? FBWhat if Impl::doSomething() would accept exactly two parameters, but FBexpects 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. FBIMO 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 20 Apr 2004 at 17:55, Stanislav Malyshev wrote:
FBImpl 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...
FBWhat if Impl::doSomething() would accept exactly two
parameters, but
FBexpects 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
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: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
[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
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
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
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
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
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
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
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
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
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 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
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
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
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 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
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
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
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
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
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
