On Wed, 8 Oct 2003, Zeev Suraski wrote:
> I don't think it extends there very naturally, or at all for that
> matter. NULL is special because it's what empty variables evaluate to, and
> makes for a very typical initial value of an array.
I agree with that, allowing NULL instead of an array is
At 15:07 08/10/2003, Ilia Alshanetsky wrote:
On October 8, 2003 08:53 am, Zeev Suraski wrote:
> >However, please note the following:
> >1) Functionality was NOT changed in 4.3.4 a mere advisory was added
> > indicated a behavior change in PHP5.
>
> What do you mean by a mere advisory?
In 4.3.X the
On October 8, 2003 08:53 am, Zeev Suraski wrote:
> >However, please note the following:
> >1) Functionality was NOT changed in 4.3.4 a mere advisory was added
> > indicated a behavior change in PHP5.
>
> What do you mean by a mere advisory?
In 4.3.X the patch only added E_NOTICE that majority of u
At 14:34 08/10/2003, Ilia Alshanetsky wrote:
On October 8, 2003 05:12 am, Zeev Suraski wrote:
> The fact of the matter is that other than your opinion (which several
> people may support), there was and still isn't nothing problematic with
> silently ignoring NULL arrays.
Jay's patch was already re
On October 8, 2003 05:12 am, Zeev Suraski wrote:
> The fact of the matter is that other than your opinion (which several
> people may support), there was and still isn't nothing problematic with
> silently ignoring NULL arrays.
Jay's patch was already reverted by Jani so arguing this point is most
On Wednesday, Oct 8, 2003, at 13:48 Europe/Copenhagen, Anil
Madhavapeddy wrote:
On Wed, Oct 08, 2003 at 01:23:42PM +0200, Edin Kadribasic wrote:
No this behavior hasn't been changed. I just thought that no harm
would
be done if it was changed and no warning was issued.
I think the point is to mi
On Wed, Oct 08, 2003 at 01:23:42PM +0200, Edin Kadribasic wrote:
>
> No this behavior hasn't been changed. I just thought that no harm would
> be done if it was changed and no warning was issued.
I think the point is to minimise the number of changes in this
``bug-fix release'', and that applie
On Wednesday, Oct 8, 2003, at 12:49 Europe/Copenhagen, Zeev Suraski
wrote:
At 11:49 08/10/2003, Edin Kadribasic wrote:
On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski
wrote:
The fact of the matter is that other than your opinion (which
several people may support), there was
At 11:49 08/10/2003, Edin Kadribasic wrote:
On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski wrote:
The fact of the matter is that other than your opinion (which several
people may support), there was and still isn't nothing problematic with
silently ignoring NULL arrays.
I ho
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
> On October 7, 2003 08:45 pm, Jan Schneider wrote:
> > I never said that the current behaviour is in any way consistent. But
> which
> > behaviour the more logical one is, is debateable. Many languages
> support
> > context dependant implicit castin
On Wednesday, Oct 8, 2003, at 11:12 Europe/Copenhagen, Zeev Suraski
wrote:
The fact of the matter is that other than your opinion (which several
people may support), there was and still isn't nothing problematic
with silently ignoring NULL arrays.
I hope the same reasoning, which I completely ag
At 10:10 08/10/2003, Derick Rethans wrote:
On Tue, 7 Oct 2003, Jon Parise wrote:
> On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote:
>
> > On October 7, 2003 08:19 pm, Jon Parise wrote:
> > > By your definition, the code was "proper" (i.e. did not generate
> > > warnings) until the
At 10:06 08/10/2003, Derick Rethans wrote:
On Tue, 7 Oct 2003, Jon Parise wrote:
> On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote:
>
> > Perhaps, if PEAR developers wrote proper code & did not rely upon
> > unsupported & undocumented features we would not have this problem.
> > W
At 03:00 08/10/2003, Ilia Alshanetsky wrote:
On October 7, 2003 08:45 pm, Jan Schneider wrote:
> I never said that the current behaviour is in any way consistent. But which
> behaviour the more logical one is, is debateable. Many languages support
> context dependant implicit casting, and PHP even
On Tue, 7 Oct 2003, Jon Parise wrote:
> On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote:
>
> > On October 7, 2003 08:19 pm, Jon Parise wrote:
> > > By your definition, the code was "proper" (i.e. did not generate
> > > warnings) until the underlying rules were changed, and I'm su
On Tue, 7 Oct 2003, Jon Parise wrote:
> On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote:
>
> > Perhaps, if PEAR developers wrote proper code & did not rely upon
> > unsupported & undocumented features we would not have this problem.
> > While they do, these problems will occur. I
On October 7, 2003 08:47 pm, Jon Parise wrote:
> No, I'm not. I'm saying it used to run without producing any errors,
> and that status quo should be preserved in a bugfix release. Aside
> from being "illogical" and inconsistent, I don't see how changing this
> behavior qualifies as a bug fix.
T
On October 7, 2003 08:45 pm, Jan Schneider wrote:
> I never said that the current behaviour is in any way consistent. But which
> behaviour the more logical one is, is debateable. Many languages support
> context dependant implicit casting, and PHP even says so explicitely in the
> manual. Why shou
On Tue, Oct 07, 2003 at 08:36:11PM -0400, Ilia Alshanetsky wrote:
> On October 7, 2003 08:19 pm, Jon Parise wrote:
> > By your definition, the code was "proper" (i.e. did not generate
> > warnings) until the underlying rules were changed, and I'm sure we all
> > agree that that's a silly definitio
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
>$a = null;
> sort($a);
> ?>
>
> Majority (if not all) array function, will error out when they encounter
> a
> variable that is not array when an array argument is expected. If
> anything
> this patch add consistency that helps to ma
Majority (if not all) array function, will error out when they encounter a
variable that is not array when an array argument is expected. If anything
this patch add consistency that helps to make code clearer. Heck, Is suspect
a far number of people will be able to find bugs in their code beca
On October 7, 2003 08:19 pm, Jon Parise wrote:
> By your definition, the code was "proper" (i.e. did not generate
> warnings) until the underlying rules were changed, and I'm sure we all
> agree that that's a silly definition of "proper code".
Well, you are claiming that a code that relies on an i
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
> Perhaps, if PEAR developers wrote proper code & did not rely upon
> unsupported
> & undocumented features we would not have this problem. While they do,
> these
> problems will occur. If you do not write proper code, either don't turn
> on
> warnin
On Mon, Oct 06, 2003 at 07:10:20PM -0400, Ilia Alshanetsky wrote:
> > Have you tried running "pear list" recently?
> >
> > We REALLY should remove the E_NOTICE part as Jan very sensibly
> > pointed out it would cause problems. Well, the first of these is in our
> > very own distro.
>
> Perhaps, i
Perhaps, if PEAR developers wrote proper code & did not rely upon unsupported
& undocumented features we would not have this problem. While they do, these
problems will occur. If you do not write proper code, either don't turn on
warnings & notices (that supposed to help you write proper code) o
On Tue, Oct 07, 2003 at 03:18:59PM +0200, Derick Rethans wrote:
> > What is the problem with array_* functions casting implicitely? The vast
> > majority of php functions does implicit casting, array_splice does it,
> > everyone is used to it, PHP is known for it... why go the other way now?
>
> B
On Tue, 7 Oct 2003, Stefan Walk wrote:
> On Tue, Oct 07, 2003 at 02:40:19AM +0300, Jani Taskinen wrote:
> >
> > Passing array_merge*() anything else but arrays is undocumented.
> > These functions were meant to be used on arrays and this change
> > (very, VERY minor change, if I may s
On Tue, Oct 07, 2003 at 02:40:19AM +0300, Jani Taskinen wrote:
>
> Passing array_merge*() anything else but arrays is undocumented.
> These functions were meant to be used on arrays and this change
> (very, VERY minor change, if I may say so) just "fixes" this.
>
> RTFM. :)
>
Zitat von Jay Smith <[EMAIL PROTECTED]>:
> Most of the other array functions are more stringent -- they don't throw
> E_NOTICEs, they throw E_WARNINGs. array_intersect(), array_diff() and
> array_sum() being the ones that I can think of offhand.
This might be true, but the str_* functions for exa
Most of the other array functions are more stringent -- they don't throw
E_NOTICEs, they throw E_WARNINGs. array_intersect(), array_diff() and
array_sum() being the ones that I can think of offhand.
J
Jan Schneider wrote:
> Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
>
>> Passing array_m
Zitat von Jani Taskinen <[EMAIL PROTECTED]>:
> Passing array_merge*() anything else but arrays is undocumented.
> These functions were meant to be used on arrays and this change
> (very, VERY minor change, if I may say so) just "fixes" this.
The only case I really care about are NULLs
t;Jay Smith" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Monday, October 06, 2003 6:51 PM
>Subject: Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing
>"false" as argument (silent when non-array is passed)
>
>
>> Jan Schneider wrote:
&
>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 06, 2003 6:51 PM
Subject: Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing
"false" as argument (silent when non-array is passed)
> Jan Schneider wrote:
> >
> > Will this be fixed before the 4.3.4 release
Jan Schneider wrote:
>
> Will this be fixed before the 4.3.4 release?
This is Ilia's release, and he's made it clear he'd rather see it in there
(as would I, given that there probably won't be a 4.4 release between 4.3
and 5.0) so as far as I know, the current code is remaining.
J
--
PHP Inte
Mike Robinson wrote:
Jay Smith wrote:
As near as I can tell, leaving it in seems to be the way to go at the
moment. Being as they're E_NOTICEs and not full-on E_WARNINGs and the fact
that the actual behaviour of the function hasn't changed (except, of
course, the E_NOTICEs), it seems to be a goo
Jay Smith wrote:
> As near as I can tell, leaving it in seems to be the way to go at the
> moment. Being as they're E_NOTICEs and not full-on E_WARNINGs and the fact
> that the actual behaviour of the function hasn't changed (except, of
> course, the E_NOTICEs), it seems to be a good reminder t
Jan Schneider wrote:
> I *love* it when threads silently die. ;-)
>
> Will this problem actually adressed by anyone or will we again have to
> release new versions of our software just because a minor PHP came out or
> deal with a huge amount of user complaints?
>
Yeah, it kind of just trailed
I *love* it when threads silently die. ;-)
Will this problem actually adressed by anyone or will we again have to
release new versions of our software just because a minor PHP came out or
deal with a huge amount of user complaints?
Zitat von Jan Schneider <[EMAIL PROTECTED]>:
> Zitat von Jay Smi
Zitat von Jay Smith <[EMAIL PROTECTED]>:
> Jan Schneider wrote:
>
> >
> > I generally agree (this is the purpose of E_NOTICE after all), but
> there
> > is a subtle difference between what has been fixed and what is broken
> now.
> > Passing NULLs to array_merge didn't lead to the borked arrays th
Jan Schneider wrote:
>
> I generally agree (this is the purpose of E_NOTICE after all), but there
> is a subtle difference between what has been fixed and what is broken now.
> Passing NULLs to array_merge didn't lead to the borked arrays that have
> been "fixed" by this patch.
>
How are the ar
Zitat von Ilia Alshanetsky <[EMAIL PROTECTED]>:
> In my opinion the change is fine, given the current state of affairs a
> transitional release between 4.3 & 5.0 does not seem likely. Therefor it
> would only seem logical to give people a fair warning (E_NOTICE) that the
> (wrong) behavior they ar
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_
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
In my opinion the change is fine, given the current state of affairs a
transitional release between 4.3 & 5.0 does not seem likely. Therefor it
would only seem logical to give people a fair warning (E_NOTICE) that the
(wrong) behavior they are relying upon is not going work/last forever.
Otherw
Wez Furlong wrote:
>
> 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'
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 bu
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
47 matches
Mail list logo
