Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4553
Return-Path: <jay@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 28083 invoked by uid 1010); 23 Sep 2003 15:44:32 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 28057 invoked by uid 1007); 23 Sep 2003 15:44:31 -0000
Message-ID: <20030923154431.28056.qmail@pb1.pair.com>
To: internals@lists.php.net
Reply-To: jay@php.net
Mail-Copies-To: jay@php.net
Date: Tue, 23 Sep 2003 11:44:29 -0400
References: <1064324106.4qf5jx9xw2yo@217.255.147.155>
Lines: 29
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
X-Posted-By: 216.94.11.234
Subject: Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
From: jay@php.net (Jay Smith)


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.)

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? Personally, I think it's
more consistent if it acts like the other array functions, but if it's
causing a lot of headaches... 

Just a thought -- perhaps keep it in for the first 4.3.4 RC and gauge the
reaction and go from there?

J


Jan Schneider wrote:

> Hi,
> 
> the recent change to array_merge that now checks for IS_ARRAY breaks BC
> IMO. At least I know get a lot of E_NOTICEs everywhere.
>