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
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 w
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
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 line
On Sat, Apr 3, 2010 at 13:43, Pierre Joye wrote:
> hi,
>
> On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev 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 i
hi,
On Sat, Apr 3, 2010 at 3:17 AM, Stanislav Malyshev 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 believing an
