Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E764137.9080507@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>
	<CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com>
	<4E764137.9080507@sugarcrm.com>
Date: Mon, 19 Sep 2011 01:21:24 +0200
Message-ID: <CAEZPtU6yBMP3X8_EpUXauDifAWEJwXS4fki5HtYNybWoCQ0kFw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, 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
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Sun, Sep 18, 2011 at 9:06 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> There's no matter of "breaking BC" - there's no BC issues with dropping
> error messages, nobody's code relies on generating fatal errors for specific
> code.

Btw, afair there is and was no BC as it was introduced with the
abstract support.

>> 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
>
> What's the point of "enforcing" such signatures?

The key word missing here is "compatible". We enforce (or should)
compatible signatures. And that makes totally sense.

> The only point I know is
> that you could call these methods with specific parameters and have it work.
> In the example it is possible. Enforcing for the sake of enforcing is
> meaningless purism,

Are you saying that extending a class and making the constructor
incompatible with the extended class is a good thing to allow and to
do? If yes then I'd to strongly disagree with this idea as it allows
very bad practices (and we have enough opportunities already to shoot
ourselves in the head).

> No it is not. The signature tells "this method would accept certain
> arguments". If you call it with these arguments, it would work. However,
> there's no promise to never extend the cases where it works - it goes
> contrary to the whole point of OOP to say "I will never loosen preconditions
> on my methods".

And finally, the reason why abstract differs from the other areas is
that they are newer. It was decided not to break BC for the other
cases where we should have done the same. While Marcus wanted to do it
everywhere, with the same good reasons.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org