Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56388
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EC578C9.4000408@ralphschindler.com>
References: <4EC578C9.4000408@ralphschindler.com>
Date: Fri, 18 Nov 2011 10:29:18 +0100
Message-ID: <CAEZPtU6pgOoEwexbFtBraBhgXJUCYk=Qhop1=EbHyfK-Ntfc9g@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Thu, Nov 17, 2011 at 10:12 PM, Ralph Schindler
<ralph@ralphschindler.com> wrote:
> Hey All,
>
> Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_chec=
ks
>
> I think we need to round out this discussion on the __construct() signatu=
re
> checking in 5.4. =A0The current behavior (RC1) feels very wrong with resp=
ect
> to PHP's class based, single inheritance, multiple interface, no method
> overloading, allowed method-overriding nature.
>
> Constructors themselves, specifically in PHP, are not explicitly statical=
ly
> marked, but are "special" (even though they are part of the instance API,
> and are callable- we'll consider this an implementation detail). =A0In
> general, constructor signatures have never been (and rightfully so) gover=
ned
> by the LSP. =A0Why? For a few reasons:
>
> =A01) before calling new(), you actually don't have a subtype (yet)- the
> subtype is a *product* of new()
>
> =A02) when you call new(), you know the exact subtype you're dealing with=
.
>
> =A03) only subtypes who implement or override __construct() can know how =
to
> prepare a stateful subtype. =A0In 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 w=
hen
> a subtype has overridden __construct();
>
> =A04) 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 no=
t
> 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. =A0(Neither c# or java allow this- =
of
> course they do have the ability to overload methods in classes for the
> record. =A0In fact, static methods are not allowed either.)
>
> That said, we really should consider removing this limitation from
> constructor signature checking. =A0Not only is it a BC break, it doesn't =
make
> sense in the context of PHP.

<?php

class A {
	function __construct($a, $b) {
	}
}

class B  extends A{
	function __construct($a) {
	}
}


works.

While the following does not:

Abstract class A {
	abstract function __construct($a, $b);
}

class B extends A{
	function __construct($a) {
	}
}

does not and it is per definition correct. Abstract defines the
signature and ensures that the signature are 100% the same.

We had a long discussion about that a couple of months ago. The main
disagreement was about the interpretation of the definition of
abstract. Abstract clearly talks about signature matching, as I (and
quite a lot of other) read it.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org