Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender)
Message-ID: <4E74E5A0.2030006@sugarcrm.com>
Date: Sat, 17 Sep 2011 11:23:28 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: "RQuadling@GMail.com" <RQuadling@GMail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
In-Reply-To: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

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. For example, handling of bug #51421 seems to be wrong - 
there should be no problem if child method's signature is more 
permissive than the parent's. I do not see any point in it except 
puristic "enforcement" for the sake of enforcement, which doesn't seem 
to have any practical purpose.

As for signature being more restrictive, in general case this should not 
be allowed as it is a LSP violation. The case can be made that ctor is 
not actually called on a real object but instead are used directly and 
statically, so more restrictive ctors are OK, but this is not true in 
the case of factories - i.e., if you do something like this:

abstract class Base {
   function __construct($foo, $bar) { /* blah */ }
   function createBase($concrete, $foo, $bar) {
       if(!is_a($concrete, __CLASS__)) { throw new Exception("$concrete 
is not my descendant, can not create!"); }
       return new $concrete($foo, $bar);
   }

This would fail if some concrete descendant of Base has additional 
restrictions on its ctor. So in this case the prohibition of additional 
restrictions is appropriate as well.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227