On Sat, Apr 3, 2010 at 4:59 AM, Lonny K lon...@gmail.com wrote:
I have SVN public access and I'm trying to find the revisions that were
made
in http://bugs.php.net/bug.php?id=42838
There are no tags on array.c for this bug and the diff link that was posted
in the report no longer exists.
I
hi,
On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev s...@zend.com wrote:
What about the 5.3? (BTW, I don't see any difference between 5.3.0 and
anything later, could anybody point it to me?)
We could:
1. Kill the class-named ctors for NS in 5.3 (some BC break, though I have
hard time
On Sat, Apr 3, 2010 at 13:43, Pierre Joye pierre@gmail.com wrote:
hi,
On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev s...@zend.com wrote:
What about the 5.3? (BTW, I don't see any difference between 5.3.0 and
anything later, could anybody point it to me?)
We could:
1. Kill the
Stanislav Malyshev wrote:
Hi!
class Filter {
public function __construct() { /* construct stuff */ }
public function filter($value) { /* return filtered */ }
}
Produces:
PHP Strict Standards: Redefining already defined constructor for
class Zend\Filter\Filter in [snip file] on line [snip
On Thu, 2010-04-01 at 13:06 -0700, Stanislav Malyshev wrote:
Hi!
The patch is simple: see attached. Doesn't break any tests except for
ns_063 which specifically tests for this particular case. Any objections
to having this in 5.3?
Given the feedback on the list I think it's ok.
Please
I really doubt named parameters would have much of an impact on
anything, but I'd be willing to consider it if a clean implementation
was to show up.
I think they'd allow to manage complex parameter sets more efficiently
than with those $options arrays. But that'd probably require changing
the
I don't think thad would require thad much work. we allready have arginfo
that does type hinting...
Modifieing that to support rewrtiting param order based on reflection Info
shouldn't be that hard...
The problem however is when an function accepts varargs (usually named
...). if we however
