Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:4556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <05a601c381f3$f36e8b50$0702a8c0@TITAN>
To: <jay@php.net>, <internals@lists.php.net>
References: <1064324106.4qf5jx9xw2yo@217.255.147.155> <20030923154431.28056.qmail@pb1.pair.com>
Date: Tue, 23 Sep 2003 17:58:45 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
From: wez@thebrainroom.com ("Wez Furlong")

Hi Jay,

> 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.

yes and yes :)

Smart people (like Jan) write code that doesn't cause E_NOTICEs.
Now they are faced with code that worked flawlessly before but raises all
kinds of errors now.

Before you say that "errors shouldn't be turned on in production", don't
forget that smart people do turn off the errors, and have them go into
an error log instead.

Some people do magic and get mailed or paged when errors happen.

> 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.)

*IF* someone decides to upgrade to PHP 5, let them worry about PHP 5
behaviour
then.

> 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.

PHP is a loosely typed language.

You've suddenly made it more strict in a minor release.
Behaviour changing patches are not suitable for the *stable* branch.

> 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...

Revert - it will cause hundreds more people lots more headaches than you
were having on your own :)

> Just a thought -- perhaps keep it in for the first 4.3.4 RC and gauge the
> reaction and go from there?

No :)
RC means release candidate, which means "this is what we are going to
release
if no one finds bugs".

Actually, this is Ilia's decision, but I think we should not raise any
notices
for NULL values, for the sake of BC.  It really does suck to break code that
was working with no problems in a minor release.

If the change had been made for 4.3, or 4.4 or 5, it wouldn't matter quite
so much.
But to change it for 4.3.4 !?

--Wez.