Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.213.170 cause and error)
Message-ID: <4EC578C9.4000408@ralphschindler.com>
Date: Thu, 17 Nov 2011 15:12:41 -0600
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Changes to constructor signature checks
From: ralph@ralphschindler.com (Ralph Schindler)

Hey All,

Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_checks

I think we need to round out this discussion on the __construct() 
signature checking in 5.4.  The current behavior (RC1) feels very wrong 
with respect to PHP's class based, single inheritance, multiple 
interface, no method overloading, allowed method-overriding nature.

Constructors themselves, specifically in PHP, are not explicitly 
statically marked, but are "special" (even though they are part of the 
instance API, and are callable- we'll consider this an implementation 
detail).  In general, constructor signatures have never been (and 
rightfully so) governed by the LSP.  Why? For a few reasons:

   1) before calling new(), you actually don't have a subtype (yet)- the 
subtype is a *product* of new()

   2) when you call new(), you know the exact subtype you're dealing with.

   3) only subtypes who implement or override __construct() can know how 
to prepare a stateful subtype.  In other words, parents can't know how 
to create subtypes who implement __construct() and subtypes shouldn't be 
concerned with the implementation details of how a parent creates types 
when a subtype has overridden __construct();

   4) LSP deals with behaviors and expectations of types (read: 
objects), since the constructor is generally considered "static" in 
nature, a form of factory specific to the type its defined within, and 
since in PHP you can't do (SomeClass instanceof SomeType) and since 
(is_a('SomeClass', 'SomeType') doesn't make much sense in the context of 
classes), the constructor is not subject to instance "behavior" rules.

In general, developers shouldn't be putting abstract constructors inside 
an abstract class nor should they be putting constructors inside 
interfaces- this is a well accepted bad practice.  (Neither c# or java 
allow this- of course they do have the ability to overload methods in 
classes for the record.  In fact, static methods are not allowed either.)

That said, we really should consider removing this limitation from 
constructor signature checking.  Not only is it a BC break, it doesn't 
make sense in the context of PHP.

Thoughts?

Thanks,
Ralph Schindler