Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55492
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <CAH-PCH5YUjz-OkbJ=4ugUeaNjbAju+QXk65qtQ4cZ9dRxixV=A@mail.gmail.com>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
 <CAF+90c-YsWFtZVPajiUL6SKvde=EyVsSGAgWZrCCvT3Y9Q9YCw@mail.gmail.com> <CAH-PCH5YUjz-OkbJ=4ugUeaNjbAju+QXk65qtQ4cZ9dRxixV=A@mail.gmail.com>
Date: Sat, 17 Sep 2011 22:39:20 +0100
Message-ID: <CAKUjMCUjjVSf7XV6mr80nc_dTmELkd-2bb5=RoDueHs-ta2nLQ@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Nikita Popov <nikita.ppv@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: rquadling@gmail.com (Richard Quadling)

On 17 September 2011 15:52, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> maybe Richard referring to https://bugs.php.net/bug.php?id=3D55085 ?
> but those change only affects the abstract classes.
>
> Tyrael
>
> On Sat, Sep 17, 2011 at 3:43 PM, Nikita Popov <nikita.ppv@googlemail.com>=
 wrote:
>> Hi Richard!
>>
>> Which change are you talking about? I just tried doing:
>> =C2=A0 =C2=A0<?php
>> =C2=A0 =C2=A0class A =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 { public functio=
n __construct($a) =C2=A0 =C2=A0 { } }
>> =C2=A0 =C2=A0class B extends A { public function __construct($a, $b) { }=
 }
>> And it worked on 5.4 Beta 1 without errors.
>>
>> Nikita
>>
>> On Sat, Sep 17, 2011 at 3:27 PM, Richard Quadling <rquadling@gmail.com> =
wrote:
>>> Hi.
>>>
>>> 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?
>>>
>>> You can always supply them and use func_get_args() / func_num_args() /
>>> etc. to read them.
>>>
>>> It would seem that the limitation restricts the capabilities. I'm not
>>> a purist. Software development is a compromise between purity and
>>> getting the job done in an efficient and understandable manner.
>>>
>>> By allowing undocumented parameters to the constructor (due to the
>>> enforced signature), this would seem to break things on a different
>>> front (I can't docblock non defined parameters for examples).

My question was due to the documentation commit
http://news.php.net/php.doc.cvs/8818 and
http://news.php.net/php.doc.cvs/8819.

Not being an expert, so I don't know all the theory, but it would seem
an abstract class defines the idea and the concrete class defines it
more - I need a better grasp of words here.

An interface is the absolute here. Sub classes (the super class being
abstract or otherwise), should be able to define MORE parameters (with
or without default values). Otherwise they aren't extending, but
implementing - and for me that's the role of an interface.

It is only interfaces that guarantee things because the interface IS
the guarantee.

A class isn't beholden to anything it inherits. You can override
methods, completely obscuring the super class if you so want.

A subclass can completely divorce itself from the superclass.

But not with an interface.


PHP has always been a very very flexible language. I feel that if a
developer absolutely must enforce a method's signature, then an
interface is going to do that 100% and is a relatively easy way to do
things. Enforcing method signatures in subclasses (I don't know why
abstract classes are treated differently) does sort of make the
interface redundant.

Unless there is a real issue with the internal engine, then the method
signatures should be flexible. Unless an interface is used.

Richard.
--=20
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea