Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55502
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E76320F.6010904@sugarcrm.com>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
	<4E74E5A0.2030006@sugarcrm.com>
	<alpine.DEB.2.02.1109181708480.3630@whisky>
	<4E76320F.6010904@sugarcrm.com>
Date: Sun, 18 Sep 2011 20:23:39 +0200
Message-ID: <CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Derick Rethans <derick@php.net>, "RQuadling@GMail.com" <RQuadling@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: nikita.ppv@googlemail.com (Nikita Popov)

On Sun, Sep 18, 2011 at 8:01 PM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> 3. Some of them aren't actually a warnings but fatal errors. Example:
>
> abstract class BaseClass {
> =A0 =A0abstract public function foo(Type1 $foo, Type2 $bar);
> }
>
> class ExtendedClass extends BaseClass {
> =A0 public function foo() {
> =A0 }
> }
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 exte=
nd
> foo() this way and there's no reason why abstracts are treated differentl=
y
> 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