Req #40799 [Com]: change string conversion behaviour for objects not implementing __toString()
Edit report at https://bugs.php.net/bug.php?id=40799&edit=1 ID: 40799 Comment by: oliver dot graetz at gmx dot de Reported by:oliver dot graetz at gmx dot de Summary:change string conversion behaviour for objects not implementing __toString() Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: any PHP Version:5.2.1 Block user comment: N Private report: N New Comment: First of all: Fixing the DateTime class is a good start but this is really just one of many problems. Four and a half years have passed and with the current PHP the problem still persists: Put any object not implementing __toString() into code where it is converted to string (for example using "implode()") and you get a catchable fatal error. PHP is a language ultimately designed to produce strings in 99.999% of all calls to any PHP script. Introducing language changes that make this harder is not a good idea. There are many situations when code runs through a list or hierarchy of variables. The current situation forces the programmer to check whether a cast to string for any variables is safe: $printable = (!is_object($var) or method_exists($var, '__toString')); This is really a joke on its own: For arrays and even resources there is a fallback (e.g. "Resource id #17"), only for objects someone decided that it would be a good idea to instead produce catchable fatal errors under certain circumstances. For me there currently remain some questions: 1. Why is there still no output for engine internal classes like DateTime where there is good reason to actually provide a default output? 2. Why is there no "is_printable($var)" function if PHP changed to a language where not all variables can be printed? The above code should not be needed to answer such a basic question. Thinking about a "Printable" interface would also be a good idea if the current situation with triggering errors remains. 3. Why is there a fallback "Array" for arrays but not "Object" or something else for objects not providing the __toString method? 4. Why does this have to be a catchable fatal error that forces the programmer to provide an error handler that purposely ignores it to continue script execution? Wouldn't an E_WARNING have sufficed? Previous Comments: [2010-02-16 22:24:56] none at mialinator dot com just fix datetime! ------------------------ [2007-03-14 03:51:50] oliver dot graetz at gmx dot de Description: Yes, I read the upgrade guide and the other bug reports regarding this topic so this is not a bug report but a plea for reconsideration. I really like that finally __toString() works in every situation but the inability to output object instances without __toString() defined is just too annoying. PHP preaches the KISS principle and on this issue the language is breaking its own rules. First of all, there are engine internal classes where the programmer is unable to provide a __toString method. Subclassing all of these classes upon usage just "to be on the safe side" is nonsense. If object output can't be changed to provide a fallback if __toString() is missing then at least all engine internal classes should implement their own default output. Secondly, for safety many programmers might be tempted to make all classes extend a common superclass just "to be on the safe side". This is braindead for the sake of any OOP concept but I already see some guys on the horizon ready to do it. And at last: There are so many convenient functions that just break if their input contains "problem objects". It just makes no sense that PHP forces me to implement an "object safe" version of implode()! I just had to do that and the loss of performance makes me shudder. Rasmus once said that PHP should only be a frontend for "PHP templates" that make use of as much precompiled code as possible. So why are these "templates" forced to implement ever more stuff in the userland? Suggestions: - at least implement default output for all engine internal classes - change __toString() to have a fallback, even "[__toString() missing]" improves on the current situation -- if this isn't POSSIBLE: PLEASE clearly state why at prominent places in the documentation. -- if this isn't WANTED: make it configurable or better, add a magic function, for example __tostring_fallback(), which should return a string. If it doesn't exist or doesn't return a string: go ahead raising the recoverable error! Abusing an error handler to do this is NOT a solution. Reproduce code: --- https://bugs.php.net/bug.php?id=40799&edit=1
[PHP-BUG] Bug #51622 [NEW]: ArrayObject shows inconsistent behaviour
From: Operating system: PHP version: 5.2.13 Package: SPL related Bug Type: Bug Bug description:ArrayObject shows inconsistent behaviour Description: This bug refers to my report filed under http://bugs.php.net/bug.php?id=34783 which is now more than four years old. In the meantime I found out that using ArrayObject instead of the test class the $t['huba'][]='three'; actually works, thanks to the SPL using its "implemented in C advantage" to circumvent the problem. Actually, it works until the programmer decides to inherit from ArrayObject and overwrite offsetGet(). Then the problem of the offsetGet() method not returning by reference is back. Back in 2005 you were very quick to flag the report as BOGUS, but a look at the source code of "zend_interfaces.c" proves that there is in fact a problem: ZEND_BEGIN_ARG_INFO_EX(arginfo_arrayaccess_offset_get, 0, 0, 1) /* actually this should be return by ref but atm cannot be */ The best way of dealing with this is not to mark it as BOGUS and deny that there is a problem. It would be admitting the fault and perhaps introducing an alternative NewArrayAccess interface that defines &offsetGet(). So future code can use it without breaking old implementations. Test script: --- Array ( [0] => one [1] => two [2] => three ) ) Test2 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Actual result: -- Test1 Object ( [huba] => Array ( [0] => one [1] => two [2] => three ) ) Notice: Indirect modification of overloaded element of Test2 has no effect in F:\huba.php on line 17 Test2 Object ( [huba] => Array ( [0] => one [1] => two ) ) -- Edit bug report at http://bugs.php.net/bug.php?id=51622&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51622&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51622&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51622&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51622&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51622&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51622&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51622&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51622&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51622&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51622&r=support Expected behavior: http://bugs.php.net/fix.php?id=51622&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51622&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51622&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51622&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51622&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51622&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51622&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51622&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51622&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51622&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51622&r=mysqlcfg
#47981 [Csd]: error handler not called regardless
ID: 47981
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows Vista x64 SP1
PHP Version: 5.2.9
Assigned To: bjori
New Comment:
If I analyzed the diffs of the last snapshots correctly, the this issue
was more esoteric the I imagined, since my test triggered the only use
of E_STRICT happening at compile time, that therefore did not use
php_error_docref().
Note to self: This problem is very loosely connected to
http://bugs.php.net/bug.php?id=41461 because the E_STRICT is not
triggered when not implementing an (empty or non-empty) interface.
Previous Comments:
[2009-04-16 13:56:10] bj...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-04-16 08:42:24] oliver dot graetz at gmx dot de
Bug system forgot to reinclude PHP version after CAPTCHA problem.
[2009-04-16 08:39:12] oliver dot graetz at gmx dot de
Description:
In the documentation of the set_error_handler it says:
It is important to remember that the standard PHP error handler is
completely bypassed. error_reporting() settings will have no effect and
your error handler will be called regardless
This is wrong! Errors of type E_STRICT will only trigger the custom
error handler function if error_reporting explicitly includes them. This
clearly means that error_reporting() settings HAVE an effect.
Personally, I think this is an error in PHP and that the behaviour of
PHP should be changed to fit the description in the documentation but
from the current point this is at least a documentation problem.
Reproduce code:
---
// --- file 'errorhandler.php'
'E_WARNING', E_NOTICE=>'E_NOTICE', E_STRICT=>'E_STRICT'
);
function handleError($errno,$errstr,$errfile,$errline,$errcontext)
{
echo "$errno (".$GLOBALS['errormap'][$errno].": $errstr\n";
}
set_error_handler('handleError');
// --- file 'tester.php' --
http://bugs.php.net/?id=47981&edit=1
#43677 [Com]: Inconsistent behaviour of include_path set with php_value
ID: 43677 Comment by: oliver dot graetz at gmx dot de Reported By: root at net1 dot cc Status: Open Bug Type: Safe Mode/open_basedir Operating System: FreeBSD 6.2 PHP Version: 5.2.5 New Comment: In order to avoid getting my report marked as a duplicate of this one: I have experienced a similar problem with PHP 5.2.5. I am using set_include_path() but the PHP ignores the call and uses the value defined in the main php.ini file. Previous Comments: [2008-02-26 12:22:18] manuel at mausz dot at Yes. The bug only occurs if you're mixing php_admin_value and php_value with the same ini-setting. [2008-02-26 11:18:06] admin at scuolacomunicazioneiulm dot it I've exactly the same system of [ryan at djurovich dot com] Plesk 8.3.0 CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 updated this night :( (oh, don't I could sleep, don't?!) I think this bug is going to become so much serious as Plesk users update their systems! Error could be seen in www.fondazioneiulm.it and www.scuolacomunicazioneiulm.it. These sites are both built on Zend Framework, like [it at inmolinkmls dot com] application. Some request load Zend/Loader.php, some not (but I have "display_errors = off", so you'll see a blank page instead of error). Do you think that the hack to change php_admin_value to php_value in Plesk confs could patch this kind of situation? MP [2008-02-25 05:39:06] ryan at djurovich dot com Confirmed, running server with Plesk 8.3.0: CentOS 4 linux 2.6.9-023stab033.9-enterprise apache 2.0.52-32.3 php 5.2.5-4 [2008-02-21 18:40:36] root at net1 dot cc I can confirm both of Manuel's patches fix the problem on another machine, too. Also, the first patch is used in production since it was made, and I have not encountered any problems up to now. It's high time devs look at this issue, isn't it? [2008-02-21 12:56:43] tallyce at gmail dot com See also bug http://bugs.php.net/bug.php?id=44178 which I now see describes the same behaviour. 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/43677 -- Edit this bug report at http://bugs.php.net/?id=43677&edit=1
#41698 [Fbk->Opn]: float parameters truncated to integer in prepared statements
ID: 41698
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux/Debian/Dotdeb
PHP Version: 5.2.3
New Comment:
The PDO driver is pdo_mysql, client library version 4.1.15.
The DBMS is MySQL 5.0.41.
The system is Debian Sarge with Dotdeb packages.
Previous Comments:
[2007-06-17 14:01:31] [EMAIL PROTECTED]
What database driver are you using?
[2007-06-15 09:16:33] oliver dot graetz at gmx dot de
Description:
This is yet another locale issue...
When setting the locale to a value where "," is used as decimal point,
then float parameters are truncated to integers. My example does not use
a string for the parameter, it reaches the execute() as float value!
This means that in userland there are no other workarounds than
resetting the locale settings for the statement execution or
hand-crafting a "stringified" float value of "4.56".
Since PDO does not offer a PDO::PARAM_FLOAT constant (at least it is
not stated in the documentation) I assume that the PDO code treats the
values as string. Since the DBMS side of the PDO operation does NOT
adhere to PHP locale settings this is a serious design flaw. Statement
parameters of type float should be converted to string with "." as
decimal point regardless of the locale setting on the PHP side.
Reproduce code:
---
$pdo->exec('CREATE TABLE test(floatval DECIMAL(8,6))');
$pdo->exec('INSERT INTO test VALUES(2.34)');
$value=4.56;
$stmt=$pdo->prepare('INSERT INTO test VALUES(?)');
$stmt->execute(array($value));
Expected result:
Array
(
[0] => Array
(
[floatval] => 2.34
[0] => 2.34
)
[1] => Array
(
[floatval] => 4.56
[0] => 4.56
)
)
Actual result:
--
Array
(
[0] => Array
(
[floatval] => 2.34
[0] => 2.34
)
[1] => Array
(
[floatval] => 4.00
[0] => 4.00
)
)
--
Edit this bug report at http://bugs.php.net/?id=41698&edit=1
#41698 [NEW]: float parameters truncated to integer in prepared statements
From: oliver dot graetz at gmx dot de
Operating system: Linux/Debian/Dotdeb
PHP version: 5.2.3
PHP Bug Type: PDO related
Bug description: float parameters truncated to integer in prepared statements
Description:
This is yet another locale issue...
When setting the locale to a value where "," is used as decimal point,
then float parameters are truncated to integers. My example does not use a
string for the parameter, it reaches the execute() as float value! This
means that in userland there are no other workarounds than resetting the
locale settings for the statement execution or hand-crafting a
"stringified" float value of "4.56".
Since PDO does not offer a PDO::PARAM_FLOAT constant (at least it is not
stated in the documentation) I assume that the PDO code treats the values
as string. Since the DBMS side of the PDO operation does NOT adhere to PHP
locale settings this is a serious design flaw. Statement parameters of type
float should be converted to string with "." as decimal point regardless of
the locale setting on the PHP side.
Reproduce code:
---
$pdo->exec('CREATE TABLE test(floatval DECIMAL(8,6))');
$pdo->exec('INSERT INTO test VALUES(2.34)');
$value=4.56;
$stmt=$pdo->prepare('INSERT INTO test VALUES(?)');
$stmt->execute(array($value));
Expected result:
Array
(
[0] => Array
(
[floatval] => 2.34
[0] => 2.34
)
[1] => Array
(
[floatval] => 4.56
[0] => 4.56
)
)
Actual result:
--
Array
(
[0] => Array
(
[floatval] => 2.34
[0] => 2.34
)
[1] => Array
(
[floatval] => 4.00
[0] => 4.00
)
)
--
Edit bug report at http://bugs.php.net/?id=41698&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41698&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41698&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41698&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41698&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41698&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41698&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41698&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41698&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41698&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41698&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41698&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41698&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41698&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41698&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41698&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41698&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41698&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41698&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41698&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41698&r=mysqlcfg
#40799 [NEW]: change string conversion behaviour for objects not implementing __toString()
From: oliver dot graetz at gmx dot de Operating system: any PHP version: 5.2.1 PHP Bug Type: Feature/Change Request Bug description: change string conversion behaviour for objects not implementing __toString() Description: Yes, I read the upgrade guide and the other bug reports regarding this topic so this is not a bug report but a plea for reconsideration. I really like that finally __toString() works in every situation but the inability to output object instances without __toString() defined is just too annoying. PHP preaches the KISS principle and on this issue the language is breaking its own rules. First of all, there are engine internal classes where the programmer is unable to provide a __toString method. Subclassing all of these classes upon usage just "to be on the safe side" is nonsense. If object output can't be changed to provide a fallback if __toString() is missing then at least all engine internal classes should implement their own default output. Secondly, for safety many programmers might be tempted to make all classes extend a common superclass just "to be on the safe side". This is braindead for the sake of any OOP concept but I already see some guys on the horizon ready to do it. And at last: There are so many convenient functions that just break if their input contains "problem objects". It just makes no sense that PHP forces me to implement an "object safe" version of implode()! I just had to do that and the loss of performance makes me shudder. Rasmus once said that PHP should only be a frontend for "PHP templates" that make use of as much precompiled code as possible. So why are these "templates" forced to implement ever more stuff in the userland? Suggestions: - at least implement default output for all engine internal classes - change __toString() to have a fallback, even "[__toString() missing]" improves on the current situation -- if this isn't POSSIBLE: PLEASE clearly state why at prominent places in the documentation. -- if this isn't WANTED: make it configurable or better, add a magic function, for example __tostring_fallback(), which should return a string. If it doesn't exist or doesn't return a string: go ahead raising the recoverable error! Abusing an error handler to do this is NOT a solution. Reproduce code: --- http://bugs.php.net/?id=40799&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40799&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40799&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40799&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40799&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40799&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40799&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40799&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40799&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40799&r=support Expected behavior:http://bugs.php.net/fix.php?id=40799&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40799&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40799&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40799&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40799&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40799&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40799&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40799&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40799&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40799&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40799&r=mysqlcfg
#34783 [Bgs]: Contradictory errors using ArrayAccess
ID: 34783
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Bogus
Bug Type: SPL related
Operating System: WinXP, Debian Linux
PHP Version: 5.1.0RC1
New Comment:
Perhaps there shouldn't be afix for the reference issues since they are
not meant to happen looking at the interface. But
$data['element']['element2']="hi"; should definitely work! Perhaps a
fix to look if the first part of this code is accessing an object
instead of a real array has to be applied. An ordinary user sees
nothing of a reference. Either fix this with ArrayAccess or completely
yank the interface!
I see a future where more and more framework code is pretending to be
an array. If then users get this error message they won't understand
the world. "It's an array!? Where's the reference? Why the *#?* isn't
this working? I hate PHP5!"
If you implement code so something can look like an array than it MUST
be able to truely behave like an array.
Previous Comments:
----------------------------
[2005-10-07 22:40:50] oliver dot graetz at gmx dot de
Why did this work in 5.0.3 by using &offsetGet() and can't be made to
work in 5.1? Why would changing the interface to read &offsetGet break
anything other than the (up to now) few apps DEFINING it without the
ampersand? 5.0 didn't complain about this at all and it worked. The
issues caused by a simple change of the interface a far inferior to
those caused by the "only variables can be passed by reference" some
weeks ago. And you're avoiding more serious trouble in later versions
when more and more applications are relying on the false behaviour?
------------------------
[2005-10-07 21:41:03] oliver dot graetz at gmx dot de
Won't happen. I'm just a user of PHP. As a result, this is one more
case where using a new feature becomes impossible by breaking BC
(between 5.0 and 5.1). A yound and promising feature has to be left
behind, ArrayAccess won't be in use any more in future projects by
certain people since the desired behaviour can easily be achieved by
using ordinary methods. Syntactic sugar going to hell.
[2005-10-07 20:20:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Just to state this again: IT IS IMPOSSIBLE TO HAVE ARRAYACCESS DEAL
WITH REFERENCES.
If you don\'t like that statement i suggest you prove it wrong by
writing a patch that actually works in all cases.
------------
[2005-10-07 19:14:37] oliver dot graetz at gmx dot de
One more point: Adding the & outside of the class just allows
referencing under PHP5.0 but not under 5.1. But having references is in
no way unfixable under 5.1:
class test
{
// rest as before
function &offsetGetRef($key) { return $this->data[$key]; }
}
$t=new test();
$t['huba']=array('one','two');
$entry=&$t->offsetGetRef('huba');
$entry[]='three';
print_r($t['huba']);
Voilà! It works. Telling that it's unfixable just doesn't do the issue
justice. Perhaps the fix is more difficult but it can be done. And "we
didn't mean to support references in the first place" isn't valid since
normal arrays are meant to be used this way and ArrayAccess was meant to
mimic this for objects.
[2005-10-07 19:07:00] oliver dot graetz at gmx dot de
Sorry, I thought I checked everything but I found something similar to
this bug here as a comment:
http://bugs.php.net/bug.php?id=32983
Still, I think that
"We found out that this is not solvable without blowing up the
interface and creating a BC or providing an additional interface to
support references and thereby creating an internal nightmare -
actually i don't see a way we can make that work ever."
is not an acceptable answer. Using &offsetGet worked fine in 5.0. An,
as I found out, this works in PHP5.0 without &offsetGet:
$entry=&$test->offsetGet('valid_op');
$entry[]='three';
So, PHP5.1 didn't fix the interface parser but instead introduced a BC
break.
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/34783
--
Edit this bug report at http://bugs.php.net/?id=34783&edit=1
#34783 [Bgs]: Contradictory errors using ArrayAccess
ID: 34783
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Bogus
Bug Type: SPL related
Operating System: WinXP, Debian Linux
PHP Version: 5.1.0RC1
New Comment:
Why did this work in 5.0.3 by using &offsetGet() and can't be made to
work in 5.1? Why would changing the interface to read &offsetGet break
anything other than the (up to now) few apps DEFINING it without the
ampersand? 5.0 didn't complain about this at all and it worked. The
issues caused by a simple change of the interface a far inferior to
those caused by the "only variables can be passed by reference" some
weeks ago. And you're avoiding more serious trouble in later versions
when more and more applications are relying on the false behaviour?
Previous Comments:
--------
[2005-10-07 21:41:03] oliver dot graetz at gmx dot de
Won't happen. I'm just a user of PHP. As a result, this is one more
case where using a new feature becomes impossible by breaking BC
(between 5.0 and 5.1). A yound and promising feature has to be left
behind, ArrayAccess won't be in use any more in future projects by
certain people since the desired behaviour can easily be achieved by
using ordinary methods. Syntactic sugar going to hell.
[2005-10-07 20:20:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Just to state this again: IT IS IMPOSSIBLE TO HAVE ARRAYACCESS DEAL
WITH REFERENCES.
If you don\'t like that statement i suggest you prove it wrong by
writing a patch that actually works in all cases.
------------------------
[2005-10-07 19:14:37] oliver dot graetz at gmx dot de
One more point: Adding the & outside of the class just allows
referencing under PHP5.0 but not under 5.1. But having references is in
no way unfixable under 5.1:
class test
{
// rest as before
function &offsetGetRef($key) { return $this->data[$key]; }
}
$t=new test();
$t['huba']=array('one','two');
$entry=&$t->offsetGetRef('huba');
$entry[]='three';
print_r($t['huba']);
Voilà! It works. Telling that it's unfixable just doesn't do the issue
justice. Perhaps the fix is more difficult but it can be done. And "we
didn't mean to support references in the first place" isn't valid since
normal arrays are meant to be used this way and ArrayAccess was meant to
mimic this for objects.
[2005-10-07 19:07:00] oliver dot graetz at gmx dot de
Sorry, I thought I checked everything but I found something similar to
this bug here as a comment:
http://bugs.php.net/bug.php?id=32983
Still, I think that
"We found out that this is not solvable without blowing up the
interface and creating a BC or providing an additional interface to
support references and thereby creating an internal nightmare -
actually i don't see a way we can make that work ever."
is not an acceptable answer. Using &offsetGet worked fine in 5.0. An,
as I found out, this works in PHP5.0 without &offsetGet:
$entry=&$test->offsetGet('valid_op');
$entry[]='three';
So, PHP5.1 didn't fix the interface parser but instead introduced a BC
break.
[2005-10-07 18:33:01] oliver dot graetz at gmx dot de
Description:
I wrote a class implementing ArrayAccess that should behave like a
normal array to the outside world. So If I used an element in this
array it should be usable like any other array. But there was a problem
if the "array" elements were arrays themselves. I got this error:
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 123
OK, you want a reference, you get it. I changed offsetGet to
&offsetGet. This worked fine with PHP5.0. But in PHP5.1 the parser
became more picky about this:
Fatal error: Declaration of WAF_Config::offsetGet() must be compatible
with that of ArrayAccess::offsetGet() in myclass.php on line 234
This is correct but it makes implementing ArrayAccess in a way
consistent with ordinary arrays impossible!
Reproduce code:
---
data[$key] = $value; }
//function &offsetGet($key) { return $this->data[$key]; }
function offsetGet($key) { return $this->data[$key]; }
function offsetUnset($key)
{
if (array_key_exists($key,$this->data)) {
unse
#34783 [Bgs]: Contradictory errors using ArrayAccess
ID: 34783
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Bogus
Bug Type: SPL related
Operating System: WinXP, Debian Linux
PHP Version: 5.1.0RC1
New Comment:
Won't happen. I'm just a user of PHP. As a result, this is one more
case where using a new feature becomes impossible by breaking BC
(between 5.0 and 5.1). A yound and promising feature has to be left
behind, ArrayAccess won't be in use any more in future projects by
certain people since the desired behaviour can easily be achieved by
using ordinary methods. Syntactic sugar going to hell.
Previous Comments:
[2005-10-07 20:20:40] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Just to state this again: IT IS IMPOSSIBLE TO HAVE ARRAYACCESS DEAL
WITH REFERENCES.
If you don\'t like that statement i suggest you prove it wrong by
writing a patch that actually works in all cases.
[2005-10-07 19:14:37] oliver dot graetz at gmx dot de
One more point: Adding the & outside of the class just allows
referencing under PHP5.0 but not under 5.1. But having references is in
no way unfixable under 5.1:
class test
{
// rest as before
function &offsetGetRef($key) { return $this->data[$key]; }
}
$t=new test();
$t['huba']=array('one','two');
$entry=&$t->offsetGetRef('huba');
$entry[]='three';
print_r($t['huba']);
Voilà! It works. Telling that it's unfixable just doesn't do the issue
justice. Perhaps the fix is more difficult but it can be done. And "we
didn't mean to support references in the first place" isn't valid since
normal arrays are meant to be used this way and ArrayAccess was meant to
mimic this for objects.
[2005-10-07 19:07:00] oliver dot graetz at gmx dot de
Sorry, I thought I checked everything but I found something similar to
this bug here as a comment:
http://bugs.php.net/bug.php?id=32983
Still, I think that
"We found out that this is not solvable without blowing up the
interface and creating a BC or providing an additional interface to
support references and thereby creating an internal nightmare -
actually i don't see a way we can make that work ever."
is not an acceptable answer. Using &offsetGet worked fine in 5.0. An,
as I found out, this works in PHP5.0 without &offsetGet:
$entry=&$test->offsetGet('valid_op');
$entry[]='three';
So, PHP5.1 didn't fix the interface parser but instead introduced a BC
break.
[2005-10-07 18:33:01] oliver dot graetz at gmx dot de
Description:
I wrote a class implementing ArrayAccess that should behave like a
normal array to the outside world. So If I used an element in this
array it should be usable like any other array. But there was a problem
if the "array" elements were arrays themselves. I got this error:
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 123
OK, you want a reference, you get it. I changed offsetGet to
&offsetGet. This worked fine with PHP5.0. But in PHP5.1 the parser
became more picky about this:
Fatal error: Declaration of WAF_Config::offsetGet() must be compatible
with that of ArrayAccess::offsetGet() in myclass.php on line 234
This is correct but it makes implementing ArrayAccess in a way
consistent with ordinary arrays impossible!
Reproduce code:
---
data[$key] = $value; }
//function &offsetGet($key) { return $this->data[$key]; }
function offsetGet($key) { return $this->data[$key]; }
function offsetUnset($key)
{
if (array_key_exists($key,$this->data)) {
unset($this->data[$key]); }
}
function offsetExists($key) { return
array_key_exists($key,$this->data); }
}
$t=new test();
$t['huba']=array('one','two');
$t['huba'][]='three';
print_r($t['huba']);
Expected result:
Array ( [0] => one [1] => two [2] => three )
Actual result:
--
using offsetGet
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 17
using &offsetGet
Fatal error: Declaration of test::offsetGet() must be compatible with
that of ArrayAccess::offsetGet() in t.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=34783&edit=1
#34783 [Opn]: Contradictory errors using ArrayAccess
ID: 34783
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Open
Bug Type: SPL related
Operating System: WinXP, Debian Linux
PHP Version: 5.1.0RC1
New Comment:
One more point: Adding the & outside of the class just allows
referencing under PHP5.0 but not under 5.1. But having references is in
no way unfixable under 5.1:
class test
{
// rest as before
function &offsetGetRef($key) { return $this->data[$key]; }
}
$t=new test();
$t['huba']=array('one','two');
$entry=&$t->offsetGetRef('huba');
$entry[]='three';
print_r($t['huba']);
Voilà! It works. Telling that it's unfixable just doesn't do the issue
justice. Perhaps the fix is more difficult but it can be done. And "we
didn't mean to support references in the first place" isn't valid since
normal arrays are meant to be used this way and ArrayAccess was meant to
mimic this for objects.
Previous Comments:
----------------
[2005-10-07 19:07:00] oliver dot graetz at gmx dot de
Sorry, I thought I checked everything but I found something similar to
this bug here as a comment:
http://bugs.php.net/bug.php?id=32983
Still, I think that
"We found out that this is not solvable without blowing up the
interface and creating a BC or providing an additional interface to
support references and thereby creating an internal nightmare -
actually i don't see a way we can make that work ever."
is not an acceptable answer. Using &offsetGet worked fine in 5.0. An,
as I found out, this works in PHP5.0 without &offsetGet:
$entry=&$test->offsetGet('valid_op');
$entry[]='three';
So, PHP5.1 didn't fix the interface parser but instead introduced a BC
break.
[2005-10-07 18:33:01] oliver dot graetz at gmx dot de
Description:
I wrote a class implementing ArrayAccess that should behave like a
normal array to the outside world. So If I used an element in this
array it should be usable like any other array. But there was a problem
if the "array" elements were arrays themselves. I got this error:
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 123
OK, you want a reference, you get it. I changed offsetGet to
&offsetGet. This worked fine with PHP5.0. But in PHP5.1 the parser
became more picky about this:
Fatal error: Declaration of WAF_Config::offsetGet() must be compatible
with that of ArrayAccess::offsetGet() in myclass.php on line 234
This is correct but it makes implementing ArrayAccess in a way
consistent with ordinary arrays impossible!
Reproduce code:
---
data[$key] = $value; }
//function &offsetGet($key) { return $this->data[$key]; }
function offsetGet($key) { return $this->data[$key]; }
function offsetUnset($key)
{
if (array_key_exists($key,$this->data)) {
unset($this->data[$key]); }
}
function offsetExists($key) { return
array_key_exists($key,$this->data); }
}
$t=new test();
$t['huba']=array('one','two');
$t['huba'][]='three';
print_r($t['huba']);
Expected result:
Array ( [0] => one [1] => two [2] => three )
Actual result:
--
using offsetGet
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 17
using &offsetGet
Fatal error: Declaration of test::offsetGet() must be compatible with
that of ArrayAccess::offsetGet() in t.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=34783&edit=1
#34783 [Opn]: Contradictory errors using ArrayAccess
ID: 34783
User updated by: oliver dot graetz at gmx dot de
Reported By: oliver dot graetz at gmx dot de
Status: Open
Bug Type: SPL related
Operating System: WinXP, Debian Linux
PHP Version: 5.1.0RC1
New Comment:
Sorry, I thought I checked everything but I found something similar to
this bug here as a comment:
http://bugs.php.net/bug.php?id=32983
Still, I think that
"We found out that this is not solvable without blowing up the
interface and creating a BC or providing an additional interface to
support references and thereby creating an internal nightmare -
actually i don't see a way we can make that work ever."
is not an acceptable answer. Using &offsetGet worked fine in 5.0. An,
as I found out, this works in PHP5.0 without &offsetGet:
$entry=&$test->offsetGet('valid_op');
$entry[]='three';
So, PHP5.1 didn't fix the interface parser but instead introduced a BC
break.
Previous Comments:
------------------------
[2005-10-07 18:33:01] oliver dot graetz at gmx dot de
Description:
I wrote a class implementing ArrayAccess that should behave like a
normal array to the outside world. So If I used an element in this
array it should be usable like any other array. But there was a problem
if the "array" elements were arrays themselves. I got this error:
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 123
OK, you want a reference, you get it. I changed offsetGet to
&offsetGet. This worked fine with PHP5.0. But in PHP5.1 the parser
became more picky about this:
Fatal error: Declaration of WAF_Config::offsetGet() must be compatible
with that of ArrayAccess::offsetGet() in myclass.php on line 234
This is correct but it makes implementing ArrayAccess in a way
consistent with ordinary arrays impossible!
Reproduce code:
---
data[$key] = $value; }
//function &offsetGet($key) { return $this->data[$key]; }
function offsetGet($key) { return $this->data[$key]; }
function offsetUnset($key)
{
if (array_key_exists($key,$this->data)) {
unset($this->data[$key]); }
}
function offsetExists($key) { return
array_key_exists($key,$this->data); }
}
$t=new test();
$t['huba']=array('one','two');
$t['huba'][]='three';
print_r($t['huba']);
Expected result:
Array ( [0] => one [1] => two [2] => three )
Actual result:
--
using offsetGet
Fatal error: Objects used as arrays in post/pre increment/decrement
must return values by reference in t.php on line 17
using &offsetGet
Fatal error: Declaration of test::offsetGet() must be compatible with
that of ArrayAccess::offsetGet() in t.php on line 2
--
Edit this bug report at http://bugs.php.net/?id=34783&edit=1
#34783 [NEW]: Contradictory errors using ArrayAccess
From: oliver dot graetz at gmx dot de
Operating system: WinXP, Debian Linux
PHP version: 5.1.0RC1
PHP Bug Type: SPL related
Bug description: Contradictory errors using ArrayAccess
Description:
I wrote a class implementing ArrayAccess that should behave like a normal
array to the outside world. So If I used an element in this array it
should be usable like any other array. But there was a problem if the
"array" elements were arrays themselves. I got this error:
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference in t.php on line 123
OK, you want a reference, you get it. I changed offsetGet to &offsetGet.
This worked fine with PHP5.0. But in PHP5.1 the parser became more picky
about this:
Fatal error: Declaration of WAF_Config::offsetGet() must be compatible
with that of ArrayAccess::offsetGet() in myclass.php on line 234
This is correct but it makes implementing ArrayAccess in a way consistent
with ordinary arrays impossible!
Reproduce code:
---
data[$key] = $value; }
//function &offsetGet($key) { return $this->data[$key]; }
function offsetGet($key) { return $this->data[$key]; }
function offsetUnset($key)
{
if (array_key_exists($key,$this->data)) {
unset($this->data[$key]); }
}
function offsetExists($key) { return array_key_exists($key,$this->data);
}
}
$t=new test();
$t['huba']=array('one','two');
$t['huba'][]='three';
print_r($t['huba']);
Expected result:
Array ( [0] => one [1] => two [2] => three )
Actual result:
--
using offsetGet
Fatal error: Objects used as arrays in post/pre increment/decrement must
return values by reference in t.php on line 17
using &offsetGet
Fatal error: Declaration of test::offsetGet() must be compatible with that
of ArrayAccess::offsetGet() in t.php on line 2
--
Edit bug report at http://bugs.php.net/?id=34783&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34783&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34783&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34783&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34783&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34783&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34783&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34783&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34783&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34783&r=support
Expected behavior: http://bugs.php.net/fix.php?id=34783&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34783&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34783&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34783&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34783&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34783&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34783&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34783&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34783&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34783&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34783&r=mysqlcfg
