Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 81.169.182.136 cause and error)
Date: Sun, 5 Nov 2006 19:21:59 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1295499307.20061105192159@marcus-boerger.de>
To: Jeff Moore <jeff@procata.com>
Cc: Marcus Boerger <helly@php.net>,
	php internals LIST <internals@lists.php.net>,
	Christian Schneider <cschneid@cschneid.com>
In-Reply-To: <c470d83c90ec179c42b974785a2062eb@procata.com>
References: <A302A34A-2257-447B-A2A0-CD665F80DC47@prohost.org> <7.0.1.0.2.20061024085428.053f9cf8@zend.com> <F2137416-B788-4C8F-80C5-FEC0AFCD31D2@prohost.org> <7f3ed2c30610240757v28702861r8d5f22f7e3047e60@mail.gmail.com> <7.0.1.0.2.20061024170856.0583dd20@zend.com> <E5728B60-0A7E-4E46-93AC-103A82CE44BD@prohost.org> <1838975922.20061024205524@marcus-boerger.de> <71B5B01C-EDC5-46B0-8747-0706B2C7DF1F@prohost.org> <454B60E8.8010305@cschneid.com> <1227362691.20061103191138@marcus-boerger.de> <c470d83c90ec179c42b974785a2062eb@procata.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
From: helly@php.net (Marcus Boerger)

Hello Jeff,

Sunday, November 5, 2006, 7:09:26 PM, you wrote:

> On Nov 3, 2006, at 1:11 PM, Marcus Boerger wrote:

>>   Liskov applies to static methods as soon as calls via objects are common
>> which is true for PHP. Actually in PHP static methods are inherited as any
>> other method (also true for a lot of other languages). Now given Liskov
>>  rules you can as well add default parameter values as add new parameters
>> with default values and even change type hints (when respecting the rules
>> correctly). With C++ the first language has proven that changing default
>> parameter values is a bad idea. There however mainly because they are bound
>> at compile time based on the compile time types, which results in default
>> values that are mostly not what you would expect. In PHP it might work as
>> expected but then all programmers that come from langiages like C++ get
>> confused. Also it would disallow a few optimizer things later (going the C++
>> way of compile time function invocatoin binding). The same holds for new
>> additional parameters. In most languages that is no option because it would
>> effectively be a different function. In PHP it would eventually work but add
>> more confusion that it would help. The last point, changing type hints in
>> derived class' methods, was discussed at PDM and declined. The main reason
>> for that decision were that all languages we knew of do not support it and
>> that most people even do not understand the rules which are quite the
>> opposite of what most people think.

> Hi Marcus,

> Enlightening explanation in a long and confusing thread.

> To restate the last point for clarification, if the PHP's rules were 
> following Liskov's rules, this

> php -d"error_reporting=8191" -r 'class Foo {} class FooBar extends Foo 
> {} class T {function f(FooBar $x){}} class S extends T {function f(Foo 
> $x){}}'

> and possibly

> php -d"error_reporting=8191" -r 'class T {function f(StdClass $x){}} 
> class S extends T {function f($x){}}'

> would not be E_STRICT violations as they currently are.  In both
> examples the subclass weakens the parent classes' preconditions (type 
> hints).  So PHP's E_STRICT rules are (intentionally) 'stricter' than 
> Liskov's rules.

Yes, both above are correct for Liskov and Lambda Calculus however it
is the opposite of what most people expect. Thus we decided against it
last year. So in PHP the typehint has to be as in the root class.

Best regards,
 Marcus