2011/9/17 <de...@lucato.it>:
> Hi,
>
> I think Richards intended other methods often used in combination with
> __construct:
>
> class A { public function init($a, $b) { } }
> class B extends A { public function init($a) { } }
>
> => PHP Strict Standards: Declaration of B::init() should be compatible with
> that of A::init()
do you know any reason for this?
>
> The example with __construct() is valid (at least in 5.3).
>
>
> Devis
>
>
> On 17 September 2011 14:43, Nikita Popov <nikita....@googlemail.com> wrote:
>
>> Hi Richard!
>>
>> Which change are you talking about? I just tried doing:
>> <?php
>> class A { public function __construct($a) { } }
>> class B extends A { public function __construct($a, $b) { } }
>> And it worked on 5.4 Beta 1 without errors.
>>
>> Nikita
>>
>> On Sat, Sep 17, 2011 at 3:27 PM, Richard Quadling <rquadl...@gmail.com>
>> wrote:
>> > Hi.
>> >
>> > With the recent BC with regard the locking of the constructor's
>> > signature for subclasses, what is the expected mechanism for allowing
>> > a subclass to have additional parameters?
>> >
>> > You can always supply them and use func_get_args() / func_num_args() /
>> > etc. to read them.
>> >
>> > It would seem that the limitation restricts the capabilities. I'm not
>> > a purist. Software development is a compromise between purity and
>> > getting the job done in an efficient and understandable manner.
>> >
>> > By allowing undocumented parameters to the constructor (due to the
>> > enforced signature), this would seem to break things on a different
>> > front (I can't docblock non defined parameters for examples).
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
--
Laruence Xinchen Hui
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
