ID: 40021
Updated by: [EMAIL PROTECTED]
-Summary: assert_options(ASSERT_CALLBACK) does not return
current setting
Reported By: wharmby at uk dot ibm dot com
-Status: Wont fix
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows XP
PHP Version: 4CVS-2007-01-04 (snap)
Assigned To: iliaa
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2007-01-12 15:51:48] [EMAIL PROTECTED]
In this instance addition of RINIT done on every request for
functionality of dubious use in a non-test environment is IMO
outweighed by the performance considerations.
As such I am marking this issue as won't fix.
------------------------------------------------------------------------
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
