Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25838
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 80.74.107.235 as permitted sender)
Message-ID: <451983A3.7050805@zend.com>
Date: Tue, 26 Sep 2006 12:46:43 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Christian Schneider <cschneid@cschneid.com>
CC: Marcus Boerger <helly@php.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <4511925F.5060602@cschneid.com> <783278347.20060921074613@marcus-boerger.de> <451911E0.3010609@cschneid.com>
In-Reply-To: <451911E0.3010609@cschneid.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Parameter checking in 5.2
From: stas@zend.com (Stanislav Malyshev)

> Personally I don't need the strict OO checks for matching parameter
> lists at all, but as long as they are E_STRICT (or the like) I have no
> problem with them being done. Nevertheless I would like to relax them
> just a tiny  little bit for signature changes not having an impact of
> object compatibility.

I agree that allowing to extend method signature (albeit with notice) is 
a good thing. You could do a number of nice things with it like flexible 
interfaces receiving variable parameters - still staying with OO. E.g., 
you can do patterns like this:

abstract class Processor() {
abstract protected function process();
private function prepare() { /// do something }
public function prepare_and_process(/* variable args */) {
   $this->prepare();
   $this->process(/* some args */);
}
}

And extends it overriding only process() function having concrete 
arguments. Of course, not everybody wants it - some would miss strict 
control on process parameters - but I don't see why it should not be 
possible in PHP, for those who wants it. That's why PHP is a dynamic 
language, I think. Right now if I remove abstract from process() method 
I can do it - but why couldn't I do it with abstract too?

Interfaces don't exactly play nice with it since you can not add code to 
the interface and can not define visibility for methods.