Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <CAAyV7nGiTSohi456=jPEqm8O4jCBLkGCRmTkJtM8iPH1Oc+D=Q@mail.gmail.com>
References: <4EC578C9.4000408@ralphschindler.com> <alpine.DEB.2.02.1111180954250.5937@whisky>
 <CAEZPtU4FHG_PTezL+LbweftuRu4248Rgmo2HJLtSBFV=nNo9Lg@mail.gmail.com>
 <4ECD3A9E.7090105@ralphschindler.com> <CAAyV7nGiTSohi456=jPEqm8O4jCBLkGCRmTkJtM8iPH1Oc+D=Q@mail.gmail.com>
Date: Thu, 24 Nov 2011 10:48:18 +0000
Message-ID: <CAKUjMCVc1DPUAHXPQzy1R9pULaGurhPynLROPtiiu9amZ6rA9w@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Ralph Schindler <ralph@ralphschindler.com>, Pierre Joye <pierre.php@gmail.com>, 
	Derick Rethans <derick@php.net>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: rquadling@gmail.com (Richard Quadling)

On 23 November 2011 18:37, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Ralph:
>
> From where I'm sitting, I can see a few sane alternatives (there may
> be more, but here are the options I can see):
>
> Option 1. =C2=A0Remove signature checking from constructors all together.
> (I don't care for this, but whatever). =C2=A0Additionally, since it's not
> enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
> on definition, as it is superfluous...
>
> Option 2. =C2=A0Fix grandchild signature checking to be inline for how
> signatures work with other methods.
>
> Personally, I think option 2 is the better one. =C2=A0I see it being odd
> and inconsistent that all methods work one way, and constructors work
> differently. =C2=A0But that's just my feeling (and I know others disagree
> there).
>
> And please don't reduce the error level of a signature change (as it
> would introduce even more inconsistency)...
>
> Just my $0.02...
>
> Anthony
>
> On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
> <ralph@ralphschindler.com> wrote:
>> Internals:
>>
>> Time to summarize.
>>
>> It is clear to me that internals is divided on this issue. =C2=A0I don't=
 think
>> it's a large enough issue to drag on, even when I disagree with it - bot=
h
>> theoretically and in practice.
>>
>> For most OO developer, putting ctors as an abstract or in an interface w=
ould
>> not happen anyway, so this does not affect them.
>>
>> ** The current change represents a minor break in BC, that should be not=
ed
>> in the manual. **
>>
>> Also, a decision needs to be made on what to do with grandchildren. =C2=
=A0As I
>> mentioned, the following produces no E_FATAL and no warnings:
>>
>> =C2=A0abstract class A { =C2=A0abstract public function __construct($a, =
$b); }
>> =C2=A0class B extends A { public function __construct($a, $b) {} }
>> =C2=A0class C extends B { public function __construct(ArrayObject $d) {}
>>
>> While this is correct behavior to me (ability for concrete to use its ow=
n
>> ctor), using the *current logic* strict signature checking enforced from=
 an
>> abstract, then the above is also wrong.
>>
>> ** Can we decide what to do with that situation? **
>>
>> On 11/18/11 5:05 AM, Pierre Joye wrote:
>>>
>>> I strongly disagree, this encourages bad practices. We could however
>>> reduce the error level to warning.
>>
>> I think this is a sufficient compromise- I don't see anything E_FATAL ab=
out
>> a signature change in ctors (I actually see nothing wrong with it, but i=
t's
>> clear the community is divided there).
>>
>> ** Can we make that change? **
>>
>>
>> Thanks,
>> -ralph

What is the normal way for userland developers to learn about
constructors? Do they know about LSP? If they do, does it apply to
constructors?

A comment on StackOverflow [1]

"At its heart LSP is about interfaces and contracts as well as how to
decided when to extend a class vs. use another strategy such as
composition to achieve your goal."

I am self taught. It was always my understanding that the constructor
was special in that it is, essentially, a magic method that can only
respond to the new keyword. Being able to call the constructor
directly, ..., that does feel a little odd as I can't actually
construct a new instance that way.
Using an interface to enforce the sig is fine. That's the exact nature
of an interface, to enforce the contract by design and if the
StackOverflow comment is accurate, then my understanding of interfaces
is fine with regard to LSP.

An abstract class, by its very nature is not formed. It isn't a
contract. It is an idea and the concrete doesn't need to fit
perfectly. OK. There is some things that are fixed, method signatures
most accept the parameters defined in the subclass but can add more
(as I understand things).

But is the signature of the constructor in an abstract class to be
enforced? I feel that it shouldn't be. It is a special method.

WikiPedia [2] has an article on Constructor Overloading. It says
"Constructors, used to create instances of an object, may also be
overloaded in some object oriented programming languages.". OK, so
WikiPedia may have a different opinion tomorrow.

Whilst we don't support overloading in the same way (I think we can
simulate it with __call() easily enough with ReflectionParameter being
my friend here maybe).

We, DO, provide the tools to allow overloading and non LSP coding
practises. Is it a great leap to also allow the same flexibility with
constructors?

Regards,

Richard Quadling.

[1] http://stackoverflow.com/questions/56860/what-is-the-liskov-substitutio=
n-principle
[2] http://en.wikipedia.org/wiki/Constructor_overloading#Constructor_overlo=
ading
--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea=C2=A0:
fan.sh/6/370