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
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
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 -
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
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,
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
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
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()
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
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
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?
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
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
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
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
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
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:
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
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
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:
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
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
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,
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
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
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
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.
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
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
-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
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
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),
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
33 matches
Mail list logo
