ID: 40021 Updated by: [EMAIL PROTECTED] Reported By: wharmby at uk dot ibm dot com -Status: Assigned +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4CVS-2007-01-04 (snap) Assigned To: iliaa New Comment:
Does this happen with PHP 5.2 (latest snapshot preferrably) ?? If so, update the version to "5CVS, 4CVS (yyyy-mm-dd)" Previous Comments: ------------------------------------------------------------------------ [2007-03-24 17:08:59] [EMAIL PROTECTED] Re-opening in order to get a response to by last 2 comments on this bug. Bug was changed to WNF after my first suggested fix which I admit had a performance hit but my 2nd patch avoids these issues. If this function is not to be fixed then I need to raise a defect against the menual as it incorrectly suggests that the current setting of the callback is returned. ------------------------------------------------------------------------ [2007-01-16 09:36:28] wharmby at uk dot ibm dot com One use case I did miss in my testcase and one that highlights the need to return the current callback routine in non-testing environments. By modifying the assert_options API to return the current setting of "callback" it is possible to save the old value so that it can be restored at a later date, i.e if a routine wants to temporarily override the current callback routine. e.g /* override current callback routine */ $o = assert_options(ASSERT_CALLBACK, "new-callback"); <do whatever> /*restore callback */ assert_options(ASSERT_CALLBACK, $o); This is not possible with current code. My updated testcase: http://www.pastebin.ca/318252 ------------------------------------------------------------------------ [2007-01-15 16:42:16] wharmby at uk dot ibm dot com When you say "callback can be an array method in which case it is an array, not a string" are you referring to the fact that the callback routine can be defined as follows $newcb = array("foo","cccc"); $o = assert_options(ASSERT_CALLBACK,$newcb); where "cccc" is a method of class "foo". If so then for sure the returned value is no longer always a string and the testcase has to deal with this using is_string(), is_array etc to determine just what has been returned. Is this not acceptable ? The manual already defines the return value from assert_options() as "mixed" (some options result in a INT) although an extra line or two to explain that assert_options(ASSERT_CALLBACK) can return either a string or array would be required should this fix be accepted. Here is the simple testcase I put together to test out the fix which I believe covers all possible use cases for this API and shows how I envisaged users dealing with the returned value: http://pastebin.ca/317405 The output with fix applied is as follows: http://pastebin.ca/317408 ------------------------------------------------------------------------ [2007-01-15 15:45:42] [EMAIL PROTECTED] The patch won't work I'm afraid. The reason it won't is because a callback can be an array method in which case it is an array, not a string. ------------------------------------------------------------------------ [2007-01-15 15:28:46] wharmby at uk dot ibm dot com Thanks for taking at look at this one Ilia. Having taken onboard your concerns regarding the performance impact of my initial patch for a function which I agree has little value outside of a testing environment could I ask you to consider the following alternative fix as without the ability to query the current setting of "callback" writing tests to verify this aspect of the API's behaviour is more difficult. New patch: http://pastebin.ca/317353 This new fix has no impact on RINIT, whilst at the same time fixing the assert_options API to perform as documented in PHP manual allowing new tests to be written to verify the assert_options API. These new tests will be dropped into CVS by my colleague if the new fix is acceptable. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40021 -- Edit this bug report at http://bugs.php.net/?id=40021&edit=1
