Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Sat, 1 Mar 2008 13:53:39 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <81270253.20080301135339@marcus-boerger.de>
To: Christian Schneider <cschneid@cschneid.com>, 
	Stanislav Malyshev <stas@zend.com>
CC: internals Mailing List <internals@lists.php.net>
In-Reply-To: <47C8448C.70901@zend.com>
References: <47C84070.2030708@cschneid.com> <47C8448C.70901@zend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] OO Parameter Checking
From: helly@php.net (Marcus Boerger)

Hello Christian, Stanislav,

Friday, February 29, 2008, 6:44:44 PM, you wrote:

> Hi!

>> 1) The current checks are IMHO too strict regarding default values for
>> parameters: An inheriting class can add default values to a parameter
>> without breaking the protocol:
>> class A { function foo($x) { ... } }
>> class B extends A { function foo($x = 42) { ... } }
>> should be allowed. Only if there are fewer parameters in B::foo or if

> I think this makes sense. In fact, if B::foo() has less parameters it 
> might be OK too, since B would just ignore extra parameters (and in fact 
> it could do it anyway :)

Sounds fine to me.

Originally I thought of allowing fully correct protocol checks that would
have allowed to even change the type hints, as long as all rules are
followed. But we decided against this and instead went with a very strict
approach. Maybe it is time to limit the strictness and apply that part of
the patch.

>> 2) The current checks are IMHO too strict regarding static functions:
>> Static functions are not part of an instance's protocol (they can not be
>> passed around) and should be left out of the check the same way
>> constructors are ignored. The use case for this is a factory method:
>> class A { static function factory($size) { ... } }
>> class B extends A { static function factory($size, $color) { ... } }

> Not sure about this - might be some nasty surprises here if you 
> substitute class B for class A. Anyway, why not call B's function 
> factoryB or something? If you are only going to call it directly by 
> name, there's no difference.

The problem here starts with late static binding. So I think we need to
stay with the inheritance/protocol stack.


Best regards,
 Marcus