Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 23 Sep 2003 21:02:30 +0200
To: Jay Smith <jay@php.net>
Cc: internals@lists.php.net
Message-ID: <20030923190230.GA12872@prp0.prp.physik.tu-darmstadt.de>
References: <1064324106.4qf5jx9xw2yo@217.255.147.155> <20030923154431.28056.qmail@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030923154431.28056.qmail@pb1.pair.com>
User-Agent: Mutt/1.3.27i
Subject: Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
From: swalk@prp.physik.tu-darmstadt.de (Stefan Walk)

On Tue, Sep 23, 2003 at 11:44:29AM -0400, Jay Smith wrote:
> 
> Is this fix really causing this much grief? Throwing an E_NOTICE isn't a BC
> break. It still works as before, it just throws the E_NOTICEs now. This was
> meant to be a bridge to the behaviour used in PHP 5, which, like other
> array_*() functions, doesn't work on non-arrays at all. (Although that fix
> for PHP 5 is debatable, I suppose.)

Well, array_splice() accepts non-array arguments in the same manner that
array_merge did before, so it's as inconsistent as it was before the
'fix'.

> The function is called array_merge(), not null_merge() or string_merge().

So why does str_repeat(10,10) work? It's not called number_repeat.
PHP is a dynamically typed language, if a function gets an argument that
does not "fit" i expect it to cast, if it does make sense in any way...
and merging a single element into an existing array, or merging two
elements to form a new array does make sense IMHO. 

Of course, if a function expects a resource, a cast doesn't make much
sense - except i could think of a few cases where it could fopen() and 
fclose() a resource on the fly. Same with objects.

Btw, the default (string)$somearray output "Array" is not satisfactory
IMO, i think a join('',$array) or something like that would be more
useful - that would have the benefit of actually being useful ;)

> The change was to make it act more like other array functions, like
> array_intersect() or array_sum(), which also check parameters for arrays.

Like i said, array_splice() acts like the old array_merge()...
And this behaviour is documented.
I think adding strict checks is the wrong way, because it breaks BC (at
least it fills error logs). If a consistent behaviour is desired,
typecasts should be added to the functions which don't support it.

> What's the consensus? Keep the change or revert? Personally, I think it's
> more consistent if it acts like the other array functions, but if it's
> causing a lot of headaches... 

As you might have guessed, i'm in favour of reverting it ;)

-- 
Regards,
Stefan Walk
<swalk@prp.physik.tu-darmstadt.de>