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
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 mu
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"
functio
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 argume
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
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
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>>// "Overload
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
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 doSom
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,
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.
> C
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 -
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 abstrac
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
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 in
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 discu
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 t
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 tha
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 diffe
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 eve
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 gu
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
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
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
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 a
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
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
-Origin
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
fra
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 characte
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.
Everyth
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 th
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,
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 t
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 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
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 t
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-sof
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
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
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
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 Lis
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 par
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.
A
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 overr
44 matches
Mail list logo
