Am 28.7.2014 um 15:03 schrieb Matteo Beccati <p...@beccati.com>: > Hi everyone, > > On 28/07/2014 09:46, Michael Wallner wrote: >>>> https://bugs.php.net/patch-display.php?bug=67064&patch=bug67064-BC&revision=1402667581 >> >> +1 on Matteo's patch. Rather a single fix than a couple. >> IIRC, we also have to think about the count_elements handler. > > I committed my patch locally and I was looking into the count_elements > inconsistency, hoping to push both fixes later today. While doing that I > had an epiphany which led me to think that we have a much bigger problem > to solve. > > As it is now, the interface definition looks like: > > interface Countable { > public function count(); > } > > Yes, it might (or will, if we don't apply my patch) be called as > count($mode = COUNT_NORMAL), but the definition on the manual > (http://php.net/manual/en/countable.count.php) is wrong and can only be > considered a hint. > > To me this is quite a major gotcha. On the other hand we can't alter the > method signature, otherwise the userland code implementing Countable > will start triggering fatal errors: > > Declaration of SomeClass::count() must be compatible with > Countable::count($mode = COUNT_NORMAL) > > Which is something we could do for .NEXT maybe, but certainly not in 5.6RC3. > > My suggestion would be to revert the changes and start an RFC process to > properly fix the issue, if that's what we want. > > We could even add a new "CountableRecursive" interface that implements > "Countable" and provides count($mode = COUNT_NORMAL) if we don't want to > take the BC hit, but then again it's not 5.6RC3 material to me. > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/
Is this a problem if the interface internally doesn't expect a parameter? You're free to expect the parameter or not, where's the issue? We allow implementations to accept more optional parameters than the interface specifies, but not less. So, it seems optimal to me, to make the interface specify no parameters, then the class implementing this interface is free to accept either no parameter (= don't care about recursive) or one optional one. I'll though happily apply your patch now. Bob
