Hartmut Holzgraefe wrote:
Brad Fisher wrote:
Thus no need to rework internal parameter passing API at all.
Perhaps I'm missing something?
you missed that the parameter name information is just not available
for internal functions, the api works by parameter positions only
right now,
Hartmut Holzgraefe wrote:
Ron Korving wrote:
Let me summarize it for you then.
Advantages of named parameters over associative arrays:
- cleaner syntax
- support for type hints
- difference between required and optional parameters
- generating documentation (whether with something like phpDoc
Lukas Smith wrote:
> > Our original idea was to handle this with an if statement like so:
> > if (version_compare(phpversion(), "5.0.0") == -1) {
> > // assign factoried method to this for PHP 4
> > // $this =& ::factory();
// $this =& ::singleton();
eval('$this =& ::singleton();');
> >
Rasmus Lerdorf wrote:
> I could see people doing:
>
> class foo {
> function foo() {
>...constructor stuff...
> }
> function __construct() {
>$this->foo();
> }
> }
I actually prefer it the other way around... foo would call __construct in
PHP4, and __construct
Ferdinand Beyer wrote:
> On 18 Feb 2004 at 11:02, Brad Fisher wrote:
>
> > For one because PHP doesn't allow method overloading. If I have
> a method
> > A::foo($a), and I want to change the prototype in B to B::foo($x,
> $y), then
...snip...
> > (lik
Ferdinand Beyer wrote:
> On 17 Feb 2004 at 14:01, Brad Fisher wrote:
>
> > class D {
> > function bar() {
> > $c = new C;
> > // I'd like to call the A::foo method of C here...
> > //In PHP4, I could do something like:
>
> Why s
oo();
$this = &$othis;
} else {
... PHP 5 code with eval here ...
}
}
The only way to make the above example work is to eval the PHP4 version
(or perhaps include it?), thus incurring a performance penalty yet
again.
Any suggestions how this could be more efficient? Personally
Personally, I both like and dislike this behavior. I like it for debugging
purposes, since it allows me full control over whether I ignore
error_reporting level or perhaps just log disabled levels instead of
displaying them, etc. On the other hand, there is a minor performance issue,
but if you w
Jay Smith wrote:
> The function is called array_merge(), not null_merge() or string_merge().
> The change was to make it act more like other array functions, like
> array_intersect() or array_sum(), which also check parameters for arrays.
>
> What's the consensus? Keep the change or revert? Perso
