Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 fine... autoconverting scalars to an array sounds too magical to me. Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 patch only added E_NOTICE that majority of users block anyway and it was added to indicate a behavior change in 5.0. I felt that was a good idea since it is unlikely we'd have an in between 4.3.X - 5.0 release. This way people are made aware of the pending change. My main reason for wanting an E_NOTICE in 4.3.X was to warn people of the change (since we have an opportunity to do so) rather then have their code suddenly break when upgrading to 5.0. Well, E_NOTICE is a bit more aggressive than a mere advisory, since it plugs into your application and may effect the way it behaves... > Quite possible, but it's still debatable whether it should be that way or > not. Speaking of consistency, the class type hints in ZE2 don't prevent you > (at least by default) the ability to pass in NULL values. Extending this > to the way arrays are handled in builtin functions makes sense to me. Good point. What about other values such as bool, int, etc... We could convert them to array(bool|int|etc...) and thus allow complete non-array argument support for array functions. 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. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 users block anyway and it was added to indicate a behavior change in 5.0. I felt that was a good idea since it is unlikely we'd have an in between 4.3.X - 5.0 release. This way people are made aware of the pending change. My main reason for wanting an E_NOTICE in 4.3.X was to warn people of the change (since we have an opportunity to do so) rather then have their code suddenly break when upgrading to 5.0. > Quite possible, but it's still debatable whether it should be that way or > not. Speaking of consistency, the class type hints in ZE2 don't prevent you > (at least by default) the ability to pass in NULL values. Extending this > to the way arrays are handled in builtin functions makes sense to me. Good point. What about other values such as bool, int, etc... We could convert them to array(bool|int|etc...) and thus allow complete non-array argument support for array functions. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 reverted by Jani so arguing this point is mostly moot. Cool, I missed that, but I think it's important to have a general guideline for future cases either way. 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? 2) Nearly every single array function will return E_WARNING when it encounters and argument that is not an array or an object. 3) New argument parsing API when told to expect an array "a" will return an error when a non-array value is provided. Quite possible, but it's still debatable whether it should be that way or not. Speaking of consistency, the class type hints in ZE2 don't prevent you (at least by default) the ability to pass in NULL values. Extending this to the way arrays are handled in builtin functions makes sense to me. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 mostly moot. 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. 2) Nearly every single array function will return E_WARNING when it encounters and argument that is not an array or an object. 3) New argument parsing API when told to expect an array "a" will return an error when a non-array value is provided. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 minimise the number of changes in this ``bug-fix release'', and that applies to adding _and_ removing warnings if they aren't critical to fixing a real bug. I'm not advocating that foreach behavior should be changed in 4.3.4. I'm just saying that it would be convenient if it ignored NULL/unitialized/false value. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 applies to adding _and_ removing warnings if they aren't critical to fixing a real bug. -- Anil Madhavapeddy http://anil.recoil.org University of Cambridgehttp://www.cl.cam.ac.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 and still isn't nothing problematic with silently ignoring NULL arrays. I hope the same reasoning, which I completely agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? I think it should ignore NULL values, but non other scalar non array values can be more problematic and probably implies an error. Was this behavior changed in any way in 4.3.x? 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. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 hope the same reasoning, which I completely agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? I think it should ignore NULL values, but non other scalar non array values can be more problematic and probably implies an error. Was this behavior changed in any way in 4.3.x? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 casting, and PHP even says so explicitely in > the > > manual. Why should this now be incorrect, not logical or not "proper"? > > Incosistent behaviour is a problem, whether it is a serious problem or a > trivial one depends on a situation, however it does not change the fact > it is Agreed. But we are talking about PHP, not a nice, clean programming language. While PHP is indeed nice, it was never and still isn't very clean, for historical reasons. To make it cleaner and fix inconsistencies is a great goal if done in a new major or a single dot version. PHP 5 would be a good possibility for such changes but even then have many suggestions been dropped for bc reasons. > a problem. IMO when a function expects an array it should error out when > the > argument it recieves is not array, with a possible exception of object's > who > in ZE1 are nearly identical to arrays. Further more there is already an > fairly large number of functions of a similar function that operate in a > similar manner. It only makes sense to fix the one or two that do not. Heck, we are talking about a *bugfix* release. May I quote you're own announce message? "This release candidate contains only bug fixes, so it should be quite stable." What bug is this change to fix? There is no bug, only a inconsistency that worked perfectly for ages. And while it may be stable is makes existing apps instable. I can't believe we have to argue about this. You are going to "break" (or at least annoy user of) at least two of the biggest and mostly used PHP projects that happen to have E_ALL enabled by default. Will *you* personally subscribe to [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] and answer every single soul complaining why after upgrading to a bugfix release of PHP they are now flooded by PHP notices of code that worked flawlessly for months? You argue that this already is an E_WARNING in PHP 5 and making it an E_NOTICE in 4.3.4 would teach the users (will it? it will only teach developers) to fix unlogical code. You shouldn't call it a bugfix release then but an "educational" release. Or call it a pre-release version of PHP 5 to show users what will be completely broken if they upgrade to PHP 5. So can now someone *please* revert this in the PHP_4_3 branch, or start a voting about this, but let us stop this needless discussion. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 agree with, can be applied to foreach which now spits out a warning for non-arrays. At least reduce the warning to notice. Can you see any harm if foreach silently ignored non-array arguments (as opposed to loudly ignoring them now)? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 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 illogical and > > undocumented 'feature' is proper? > > No, I'm not. I'm saying it used to run without producing any errors, You mean just like our bison parser? If you refer to the INI parser, then it's actually an example of a change that broke compatibility, probably made after the bison people thought that nobody uses this feature. > Which just goes to show that the authors of the PEAR library (who are > not ignorant of the PHP language and its constraints) were under the > assumption that the code was correct at the time that is was written. Then they were wrong... Says who? With PHP, the number 1 source to describe the functionality is the functionality itself. Even if it was documented to the contrary, at this point I would have to say that it was the documentors (which are, like the rest of us, mere mortals that make mistakes) who were wrong. And in this case, even if the PEAR authors were wrong, why on earth force them as well as lots of others pay when you can let go on working without any drawbacks whatsoever? This unexplained will to break compatibility is something that's very difficult to understand. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. > > 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) or take the time to fix the problem. > > That's an elitist and unprofessional stance. It's not. If you misuse a language, then you pay for it. That's also an elitist statement IMHO. Are you gaining anything form making these people 'pay'? Who is to define what constitutes use and what constitutes misuse? Generally, if it works, and it's not horribly illogical, then it's a valid use. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 says so explicitely in the > manual. Why should this now be incorrect, not logical or not "proper"? Incosistent behaviour is a problem, whether it is a serious problem or a trivial one depends on a situation, however it does not change the fact it is a problem. IMO when a function expects an array it should error out when the argument it recieves is not array, with a possible exception of object's who in ZE1 are nearly identical to arrays. Further more there is already an fairly large number of functions of a similar function that operate in a similar manner. It only makes sense to fix the one or two that do not. Ilia, 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. A thing that's known to break pieces of code, must not be 'fixed' in a bug fix release - this is completely and entirely obvious IMHO, and was a rule we always tried to go by in the past. I agree with others here that whether it should be changed altogether is debatable, considering the nature of PHP, and the fact that it has no problems whatsoever to treat NULL values as empty arrays, by design. It should be debated in the context of a feature-release though, not a bug-fix release. As a rule of the thumb - if you bump into something that broke compatibility and you found it even before releasing, it means it affects TONS of users. If it was an important security issue, then it might have been worth it. If it's a small nuance about code purity, it isn't worth it... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 sure we all > > > agree that that's a silly definition of "proper code". > > > > Well, you are claiming that a code that relies on an illogical and > > undocumented 'feature' is proper? > > No, I'm not. I'm saying it used to run without producing any errors, You mean just like our bison parser? > Which just goes to show that the authors of the PEAR library (who are > not ignorant of the PHP language and its constraints) were under the > assumption that the code was correct at the time that is was written. Then they were wrong... Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. If you do not write proper > > code, either don't turn on warnings & notices (that supposed to help > > you write proper code) or take the time to fix the problem. > > That's an elitist and unprofessional stance. It's not. If you misuse a language, then you pay for it. Derick -- - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. The real fix (E_WARNING) is in PHP 5.0, in order to inform developers that a certain (incorrect in this case) behavior will no longer be supported an E_NOTICE is issued to inform them of the situation. The longer we wait the more people will rely upon invalid functionality and 24 month down the road we will have no choice but to keep brokenness in PHP due to BC issues as was the case in similar situations. > Which just goes to show that the authors of the PEAR library (who are > not ignorant of the PHP language and its constraints) were under the > assumption that the code was correct at the time that is was written. Just because something works does not mean it is correct. You can write code with only E_ERROR reporting level and have it work. But, not everyone runs with such an insanely low error reporting level. Many things work in PHP, but it does not mean using that functionality is correct. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 should this now be incorrect, not logical or not "proper"? Incosistent behaviour is a problem, whether it is a serious problem or a trivial one depends on a situation, however it does not change the fact it is a problem. IMO when a function expects an array it should error out when the argument it recieves is not array, with a possible exception of object's who in ZE1 are nearly identical to arrays. Further more there is already an fairly large number of functions of a similar function that operate in a similar manner. It only makes sense to fix the one or two that do not. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 definition of "proper code". > > Well, you are claiming that a code that relies on an illogical and > undocumented 'feature' is proper? 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. Fix it in a major revision, and we'll all be happen in 24 months or so when everyone upgrades. > PEAR is the official PHP library, which many people will undoubtedly use to > learn by example. IMHO that means that PEAR libraries especially the ones > part of the 'core' (automatically distributed) packages contain exemplary > code other people can safely learn from? Which just goes to show that the authors of the PEAR library (who are not ignorant of the PHP language and its constraints) were under the assumption that the code was correct at the time that is was written. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 make code clearer. Heck, Is > suspect > a far number of people will be able to find bugs in their code because > they > will now be warned that a function is getting a string/null/etc... > instead > silently accepting any argument. 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 should this now be incorrect, not logical or not "proper"? You can safely argue the opposite, namely that no array function should raise a warning but instead cast the value to an array. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 because they will now be warned that a function is getting a string/null/etc... instead silently accepting any argument. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 illogical and undocumented 'feature' is proper? The function documentation both in the manual & the php source comments clearly stated the the only acceptable arguments for the function are arrays. Had someone for whatever reasons converted the function to use new argument parsing API the same thing would've happened. So, unless you would like to argue that PHP's argument parsing is wrong this is not a bug. Even if we were to take other array functions into consideration, you'd notice that they would return E_WARNING let a lone a harmless E_NOTICE (blocked by most people) when passed a variable of an incorrect type. PEAR is the official PHP library, which many people will undoubtedly use to learn by example. IMHO that means that PEAR libraries especially the ones part of the 'core' (automatically distributed) packages contain exemplary code other people can safely learn from? Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 > warnings & notices (that supposed to help you write proper code) or take > the > time to fix the problem. This by no means is a problem in PHP. As Stefan pointed out with his link to the PHP manual, this acutally *is* documented, because it's an implicit cast from a simple type to an array. >From the manual: For any of the types: integer, float, string, boolean and resource, if you convert a value to an array, you get an array with one element (with index 0), which is the scalar value you started with. If you convert an object to an array, you get the properties (member variables) of that object as the array's elements. The keys are the member variable names. If you convert a NULL value to an array, you get an empty array. [...] PHP does not require (or support) explicit type definition in variable declaration; a variable's type is determined by the context in which that variable is used. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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, 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) or take the > time to fix the problem. That's an elitist and unprofessional stance. 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". > This by no means is a problem in PHP. Sorry, I forgot that PHP and PEAR must be playing on separate teams. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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) or take the time to fix the problem. This by no means is a problem in PHP. Ilia On October 6, 2003 06:42 pm, Wez Furlong 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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? > > Because it's plain wrong? Array functions should not cast any scalar to > an array, not even array_splace IMO because a scalar is NOT a non-scalar > as an array or object. The same argument works for numbers and strings, imo. They aren't the same, but there are rules for converting them. Same with Arrays and non-arrays. http://de2.php.net/manual/en/language.types.array.php#language.types.array.casting What is a problem with being able to merge a single element into an array without having to create an array around it explicitely? What is wrong with versatility? > > Btw, this `very, VERY minor change' broke pear. > > That has nothing to do with this change, just by a bad design choice. If a change breaks something in the distribution, i wouldn't call it minor, no matter what circumstances... > Once more the description in the manual: > > array_merge() merges the elements of two or more arrays together > so that the values of one are appended to the end of the > previous one. It returns the resulting array. I know the description. What does it tell me? String functions tell that they work on strings, but they accept numbers nonetheless. This fix does nothing but make PHP more inconsistent. -- Regards, Stefan Walk <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 say so) just "fixes" this. > > > > RTFM. :) > > > > --Jani > > Do you want me to fix the str* functions, since it seems those are > accepting numbers? Trying being sarcastic? Tip: it doesn't work on a mailinglist to reach some goal. > 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? Because it's plain wrong? Array functions should not cast any scalar to an array, not even array_splace IMO because a scalar is NOT a non-scalar as an array or object. > Btw, this `very, VERY minor change' broke pear. That has nothing to do with this change, just by a bad design choice. Once more the description in the manual: array_merge() merges the elements of two or more arrays together so that the values of one are appended to the end of the previous one. It returns the resulting array. regards, Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. :) > > --Jani Do you want me to fix the str* functions, since it seems those are accepting numbers? 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? Btw, this `very, VERY minor change' broke pear. -- Regards, Stefan Walk <[EMAIL PROTECTED]> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 example don't throw anything at all if you pass them a NULL. So we're inconsistent no matter what we do, it's a bogus argument. The point is that the behaviour changes in a minor release an that is A Bad Thing IMO. I'm selfish admittedly, but Horde's default configuration is to report E_ALL and we are indeed writing E_NOTICE-safe code. In the end we will be flooded with complaints on error messages from code that worked flawlessly for months or even years and still does, just because people upgraded to a *bug fix* PHP release. I'm fine with this notice to be added to the PHP_4 and HEAD branch, but PHP_4_3 is the wrong place. > Jan Schneider wrote: > > > 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 being passed to that > function. > > And we don't throw E_NOTICEs if using NULLs with any type specific > > function AFAIK. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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_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 being passed to that function. > And we don't throw E_NOTICEs if using NULLs with any type specific > function AFAIK. > > Jan. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 being passed to that function. And we don't throw E_NOTICEs if using NULLs with any type specific function AFAIK. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. :) --Jani On Mon, 6 Oct 2003, Wez Furlong 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. > >--Wez. > >- Original Message - >From: "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: >> > >> > 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. --Wez. - Original Message - From: "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: > > > > 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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? 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 good reminder that the undocumented behaviour being relied upon is subject to change. (And will change in 5, for that matter.) I'd imagine that most setups ignore E_NOTICEs, so most people won't even notice. (No pun intended, of course.) Notwithstanding its very unsafe to make such an assumption, the minority of setups affected by this change could still be in the thousands, tens or even hundreds of thousands. IMHO, if the function behaviour hasn't changed, there should be no notice warning about possible future changes. Thats what documentation and announcements are for. Will this be fixed before the 4.3.4 release? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 that the > undocumented behaviour being relied upon is subject to change. (And will > change in 5, for that matter.) > > I'd imagine that most setups ignore E_NOTICEs, so most people won't even > notice. (No pun intended, of course.) Notwithstanding its very unsafe to make such an assumption, the minority of setups affected by this change could still be in the thousands, tens or even hundreds of thousands. IMHO, if the function behaviour hasn't changed, there should be no notice warning about possible future changes. Thats what documentation and announcements are for. Regards Mike Robinson http://fiddy8.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 off at then end there, didn't it... 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 that the undocumented behaviour being relied upon is subject to change. (And will change in 5, for that matter.) I'd imagine that most setups ignore E_NOTICEs, so most people won't even notice. (No pun intended, of course.) If there's anybody else who wants to take up the issue they're more than welcome to. I prefer leaving it in, but maybe that's just me. (Well, it's not just me, actually, but you know what I mean.) J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 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 that
> have
> > > been "fixed" by this patch.
> > >
> >
> > How are the arrays borked? The patch doesn't touch, skip or otherwise
> do
> > anything to any of the parameters, it just does a type check. Am I
> > missing
> > something here? (Which is quite possible...)
>
> Ah, well, I misread the original bug report. With "borked" I meant that
> array_merge(false, array("foo" => "bar")) resulted in array(0 => false,
> "foo" => "bar"). I though this was changed by the patch.
>
> Anyway, array_merge(array("foo" => "bar"), null) was never producing such
> an
> array and should thus not result in an E_NOTICE.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 that have
> > been "fixed" by this patch.
> >
>
> How are the arrays borked? The patch doesn't touch, skip or otherwise do
> anything to any of the parameters, it just does a type check. Am I
> missing
> something here? (Which is quite possible...)
Ah, well, I misread the original bug report. With "borked" I meant that
array_merge(false, array("foo" => "bar")) resulted in array(0 => false,
"foo" => "bar"). I though this was changed by the patch.
Anyway, array_merge(array("foo" => "bar"), null) was never producing such an
array and should thus not result in an E_NOTICE.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 arrays borked? The patch doesn't touch, skip or otherwise do anything to any of the parameters, it just does a type check. Am I missing something here? (Which is quite possible...) Or are you talking about 5.0? J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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 are relying upon is not going work/last forever. > Otherwise, without a word of warning working code will suddenly become > broken > code once they upgrade. But they would expect their code to (potentially) break if they upgrade to PHP 5.0. And it actually will, despite the efforts to make 5.0 as BC as possible. > Most people have their error reporting set to E_ALL ^ E_NOTICE (do not > display > notices) so it won't affect them anyway. Even then, the behavior itself > implies a failure in some code, since an non-array value is passed to a > function expecting an array. I venture it would help a number of people > find > errors in their code that before were nigh impossible to find and/or > track > down. 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. > And yes PHP is typeless, but all of the code using new argument parsing > functions will most definitely reject strings passed to functions > expecting > arrays and vice versa. I see this situations as not being any different. Does this apply to NULL "values" too? Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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
<[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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? Personally, I think it's
> more consistent if it acts like the other array functions, but if it's
> causing a lot of headaches...
I see no problem with the array_{merge|intersect|diff|flip|etc.} functions
taking non-array parameters, since they all _return_ the resulting array. As
long as they don't promote a non-array variable passed as a parameter into an
array as a side-effect, I don't see the problem. I'd say revert the change and
keep it as it was.
-Brad
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. Otherwise, without a word of warning working code will suddenly become broken code once they upgrade. Most people have their error reporting set to E_ALL ^ E_NOTICE (do not display notices) so it won't affect them anyway. Even then, the behavior itself implies a failure in some code, since an non-array value is passed to a function expecting an array. I venture it would help a number of people find errors in their code that before were nigh impossible to find and/or track down. And yes PHP is typeless, but all of the code using new argument parsing functions will most definitely reject strings passed to functions expecting arrays and vice versa. I see this situations as not being any different. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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't matter quite > so much. > But to change it for 4.3.4 !? > > --Wez. Point taken. I've got no great attachment to the "fix", although I do prefer the consistency with the other array functions. Would checking for IS_ARRAY and IS_NULL be too much of a kludge? J -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fwd: Re: #25494 [Com]: array_merge allowing "false" as argument (silent when non-array is passed)
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. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
