Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.v11t31uaidpuyk@clk-0081.mshome.net>
References: <CAKUjMCXiYc63NKsUuYWXT-A-aPabdPV6142LP9h4-c=2aUxW=w@mail.gmail.com>
	<4E74E5A0.2030006@sugarcrm.com>
	<alpine.DEB.2.02.1109181708480.3630@whisky>
	<4E76320F.6010904@sugarcrm.com>
	<CAF+90c8oZ4ghsFBa7jHtp_AKqD0N0cDhMycpjFTpCkLV9qRsqQ@mail.gmail.com>
	<4E764137.9080507@sugarcrm.com>
	<op.v11rqdgiidpuyk@clk-0081.mshome.net>
	<CACQesk5iSTqw4r4OVyCG5WYyYz3xie4ionhRBVj2-r_iDgznQg@mail.gmail.com>
	<op.v11s7igeidpuyk@clk-0081.mshome.net>
	<4E7708FA.7080802@sugarcrm.com>
	<op.v11t31uaidpuyk@clk-0081.mshome.net>
Date: Mon, 19 Sep 2011 11:50:37 +0200
Message-ID: <CAH-PCH5Rf0NCSCHDWpwP_oKq4GzwOCjuRMTW1rua50SR35beyA@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] __constructor parameter limitations.
From: tyra3l@gmail.com (Ferenc Kovacs)

On Mon, Sep 19, 2011 at 11:32 AM, Gustavo Lopes <glopes@nebm.ist.utl.pt> wr=
ote:
> Em Mon, 19 Sep 2011 10:18:50 +0100, Stas Malyshev <smalyshev@sugarcrm.com=
>
> escreveu:
>
>> On 9/19/11 2:12 AM, Gustavo Lopes wrote:
>>>
>>> Arbitrary as it may be, it's nevertheless reasonably arbitrated given h=
ow
>>> little useful it is to just ignore arguments and how likely it is to a
>>> mistake.
>>
>> It is not little useful and it is not likely to make such mistake withou=
t
>> immediately being notified and corrected. I don't know how you make thes=
e
>> assumptions or what they are based on - could you please bring some
>> evidence?
>
> It would obviously be hard to produce such evidence. Measuring how common
> a mistake is very difficult without some study to that effect since those
> mistakes are steeply underrepresented in the public PHP code corpus (i.e.
> they get fixed). And measuring how common overrides with less arguments
> are would still require relatively complex code analysis.
>
> So, no, I cannot prove the assertions behind my argument, I can only say =
I
> believe them to be plausible.
>
>>> And I don't buy the func_get_args() argument. Why would anyone use
>>> func_get_args for anything other than variadic functions?... I certainl=
y
>>> don't.
>>
>> So you say if you personally don't use something in PHP nobody should us=
e
>> it?
>> And, BTW, what's wrong with variadic functions (i.e., ones accepting
>> variable number of arguments)? Such functions are commonplace in PHP.
>
> The thing if you introduce func_get_args() to the argument, any discussio=
n
> about enforcing signatures becomes meaningless. One could argue this
> should be allowed:
>
> class A {
> function foo() {}
> }
>
> class B extends A {
> function foo($a) {}
> }
>
> Because for all we know the implementation of A::foo() could have:
>
> function foo() {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0$a =3D func_get_args()[0];
> }
yeah, but you can't know from the method signature that there is, or
isn't any place, where the parent method is called without arguments,
but your class would be incompatible there.

You aren't supposed to know at all time that what does the Superclass
class/method internally or how is it used at all time(where it is
called, with how many arguments, etc), but you get a guarantee that
all call for that method has to be compatible with it's method
signature, so as long as your method signature also compatible with
it, you should be fine to change it.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu