Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain procata.com from 207.58.169.145 cause and error)
In-Reply-To: <1227362691.20061103191138@marcus-boerger.de>
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>
Mime-Version: 1.0 (Apple Message framework v624)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-ID: <c470d83c90ec179c42b974785a2062eb@procata.com>
Content-Transfer-Encoding: 7bit
Cc: php internals LIST <internals@lists.php.net>,
 Christian Schneider <cschneid@cschneid.com>
Date: Sun, 5 Nov 2006 13:09:26 -0500
To: Marcus Boerger <helly@php.net>
Subject: Re: [PHP-DEV] Why 5.2 should not be delayed for E_DEPRECATED
From: jeff@procata.com (Jeff Moore)


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.

Best Regards,

Jeff