Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49467
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.193 as permitted sender)
Message-ID: <4C6D7EBD.9000104@sugarcrm.com>
Date: Thu, 19 Aug 2010 11:58:05 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Dave Ingram <dave@dmi.me.uk>, PHP Internals <internals@lists.php.net>
References: <4C6CE273.2070501@sugarcrm.com>	<4C6CE604.1010209@dmi.me.uk>	<4C6CE793.1020601@sugarcrm.com>	<4C6CEBE4.3070306@dmi.me.uk>	<4C6D6194.6010202@sugarcrm.com> <AANLkTi=R_fW=R0JzT=DhVHHBA2USycqNk8Aw_=9CeEE5@mail.gmail.com>
In-Reply-To: <AANLkTi=R_fW=R0JzT=DhVHHBA2USycqNk8Aw_=9CeEE5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] inheritance check too strict?
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> However, what are the benefits to be less strict in your example? I
> can't think of any practical (or critical) example where you have to
> remove this optional argument.

I have tons of code that does it, but the first example would be, of 
course, using func_get_args().
Another example would be if the parent function has some option and the 
child want to always have this option set to particular value or maybe 
taken not from the parameter but from some other place. He can do it in 
the code anyway, but why have an argument that is never used?

The idea is that E_STRICT warning are useful if they definitely point to 
some wrong code - like overriding foo($a) with foo($a, $b) (can't work - 
missing arg) or with foo(Bar $a) (can't work if $a is not Bar). In the 
example we discuss it definitely can work and actually does work - only 
reason to put out warning there will be misguided notions of how the 
code should be written and it ultimetely would lead people to just 
disable those warnings altogether - who needs them if they warn about 
perfectly good code and serve no purpose but to annoy people?

These things are only useful if they help. The whole notion of "you have 
to prove this code is legit" is wrong - even though, as I showed above, 
I can prove it's legit - we should only warn about the code *we* can 
prove is *not* legit. Which is definitely not the case here.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227