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,
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
