On Mon, Sep 19, 2011 at 2:24 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Mon, Sep 19, 2011 at 1:59 AM, Stas Malyshev <smalys...@sugarcrm.com> wrote:
>
>> foo() is compatible with foo($a, $b) - since anywhere you can call function
>> declared as foo($a, $b) you can also successfully call one declared as
>> foo(), it'd just ignore extra parameters - but it is not allowed (I gave an
>> example). It was bad when it was a useless E_STRICT, it is much worse when
>> it's a fatal error.
>
> It is not compatible as the two new parameters are not optional.
> foo($a=null, $b=2) would be compatible. The only difference is that
> (if we don't fail with the signature checks) warnings will be raised
> for the missing arguments. But basically the problem is actually the
> incompatible signature. Take this code:
>
> class foo{
> function __construct(){}
> }
> class bar extends foo{
> function__construct($a, $b){}
> }
>
> if (is_a('bar', 'foo')) {
> $a = new bar(); // warnings and maybe unexpected results due to the
> lack of arguments
> }
>
> to me (and to the OO concepts), they should fail at compile time to
> avoid any kind of confusions or bad consequences/usage. But I can
> understand that a fatal error could be seen as too extreme.
>
>
>>> Are you saying that extending a class and making the constructor
>>> incompatible with the extended class is a good thing to allow and to
>>> do? If yes then I'd to strongly disagree with this idea as it allows
>>
>> I never said anything about constructor being "incompatible" with extended
>> class and it being good thing. I am saying rejecting compatible but not
>> matching signatures - and I gave example of foo() vs foo($a, $b) - makes no
>> sense. And not even with E_STRICT - it's a fatal error now!
>
> Given that your example is not compatible, it is then fine to reject them.
>
>>> And finally, the reason why abstract differs from the other areas is
>>> that they are newer. It was decided not to break BC for the other
>>> cases where we should have done the same. While Marcus wanted to do it
>>> everywhere, with the same good reasons.
>>
>> I guess "all abstracts do that" is better than "abstracts except for ctors
>> do that" but only marginally as both behaviors make little sense to me.
>> Being restricted to abstracts limits the BC impact (as people could just
>> remove the abstract keyword and thus avoid trouble relatively easily) but in
>> both cases it doesn't look too good.
>
> Where is the BC impact with abstract? It was always like that. It
> happens to affect some newly written codes now but the behaviors is
> not new.
>
>> I'm not sure if we should keep the new BC-breaking error in 5.4 for
>> consistency sake (I'd felt much easier if we had discussed that before - or
>> we did and I just forgot?), but I seriously think we need to rework it in
>> 5.5 and make all compatible signatures work without complaining.
>
> Which BC break fix? afair there is one bug fix Gustavo made which
> creates bad side effects (about parent not being called or something
> like that). Etienne was planning to work on that to find a better
> solution. I don't have the bug # at hand but either Etienne or Gustavo
> could explain it better,
>
the __construct was handled differently, as the other methods, so this
was valid before 5.4:
<?php
abstract class BaseClass {
abstract public function __construct(Type1 $foo, Type2 $bar);
}
class ExtendedClass extends BaseClass {
public function __construct() {
}
}
now the constructor also uses the same restrictions for abstract
classes as the other methods.
it's not a problem in itself, I'm just answering the question that
which bugfix is Stas referring to.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
