On Sun, Sep 18, 2011 at 8:01 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> 3. Some of them aren't actually a warnings but fatal errors. Example:
>
> abstract class BaseClass {
>    abstract public function foo(Type1 $foo, Type2 $bar);
> }
>
> class ExtendedClass extends BaseClass {
>   public function foo() {
>   }
> }
Just to make sure that we all got the situation right: The above code
throws the very same error on 5.3, on 5.2 and probably every other PHP
5 version before that (http://codepad.viper-7.com/Mb9Syu,
http://codepad.viper-7.com/lwmlaQ). 5.4 only made the behavior
consistent for constructors.
I didn't see any complaints about this "feature", so I don't really
see a reason why we should break BC with 5.3 here and drop the error
message.

> This doesn't make sense on two levels: there's no reason why I can't extend
> foo() this way and there's no reason why abstracts are treated differently
> from non-abstracts.
I already tried to explain why it makes sense: An abstract method is
much like an interface. Both define signatures without implementation.
If their signatures weren't enforces, what would abstract methods be
good for? An abstract method (for me) is a way for an abstract class
to tell you: I need this and that method accepting these and these
arguments to work correctly. If the signature isn't enforced, this
doesn't make sense anymore. You could just as well drop the signature
from abstract method definitions, as it's pointless then.

Nikita

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to