Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55498
Return-Path: <derick@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 11892 invoked from network); 18 Sep 2011 15:09:23 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 18 Sep 2011 15:09:23 -0000
Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
X-PHP-List-Original-Sender: derick@php.net
X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6
Received: from [82.113.146.227] ([82.113.146.227:47286] helo=xdebug.org)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id D9/03-22692-1A9067E4 for <internals@lists.php.net>; Sun, 18 Sep 2011 11:09:22 -0400
Received: from localhost (xdebug.org [127.0.0.1])
	by xdebug.org (Postfix) with ESMTPS id B0191DE141;
	Sun, 18 Sep 2011 16:09:18 +0100 (BST)
Date: Sun, 18 Sep 2011 17:09:18 +0200 (CEST)
X-X-Sender: derick@whisky
To: Stas Malyshev <smalyshev@sugarcrm.com>
cc: "RQuadling@GMail.com" <RQuadling@GMail.com>, 
    PHP internals <internals@lists.php.net>
In-Reply-To: <4E74E5A0.2030006@sugarcrm.com>
Message-ID: <alpine.DEB.2.02.1109181708480.3630@whisky>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com> <4E74E5A0.2030006@sugarcrm.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: derick@php.net (Derick Rethans)

On Sat, 17 Sep 2011, Stas Malyshev wrote:

> On 9/17/11 6:27 AM, Richard Quadling wrote:
> > With the recent BC with regard the locking of the constructor's
> > signature for subclasses, what is the expected mechanism for allowing
> > a subclass to have additional parameters?
> 
> I think the whole "strict parameters" thing has gone into somewhat wrong
> direction and now we seem to have tons of useless errors and restrictions.

If you don't want those warnings, turn them off! That's why there is a 
specific error level for it.

Derick