ID: 39764 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Arrays related Operating System: Windows2000 PHP Version: 4.4.4 New Comment:
> Objects DO have __toString() method (and you cannot use an > object as a key without implementing this method in 5.2+), > but resources are different. > So I would actually change the E_STRICT error to E_NOTICE, > as it doesn't make much sense to me to use an internal > resource identifier as a key. Then change it to E_WARNING to be consistent with array_key_exists() and deny serialization of resources to (int) as in $array[$resource] = "value"; > This internal ID might be reused or another resource with > different ID might exist pointing to the same physical > resource (connection, structure etc.). It seems that resources are generated incrementally. <?php $xml_parser = xml_parser_create(); xml_parser_free($xml_parser); var_dump($xml_parser); $xml_parser = xml_parser_create(); xml_parser_free($xml_parser); var_dump($xml_parser); ?> The better solution would be to generate unique hash for resource, which will include resource type and ordinal. But the simple way to reach consistency on this stage is still to patch array_key_exists($resource, $array) to report correct information just like isset($array[$resource]) does. Previous Comments: ------------------------------------------------------------------------ [2006-12-07 13:11:38] [EMAIL PROTECTED] >If even experienced developers who write the manual tend >to make this kind of "mistakes" then what should we >expect from other users? Well, nobody's perfect and even experienced developers make mistakes. But that doesn't mean these mistakes should become a rule. >From the other side if we assume that PHP is OO language >then it should be indifferent to the type of object used >as array key as long as the object can be hashed and >compared to others. IIRC that is the way it works for >Python and Java (toString() method). While I can agree, that resources should have been objects and even the resource type should not exist, this is what we have to live with. Objects DO have __toString() method (and you cannot use an object as a key without implementing this method in 5.2+), but resources are different. So I would actually change the E_STRICT error to E_NOTICE, as it doesn't make much sense to me to use an internal resource identifier as a key. This internal ID might be reused or another resource with different ID might exist pointing to the same physical resource (connection, structure etc.). ------------------------------------------------------------------------ [2006-12-07 12:56:30] [EMAIL PROTECTED] If even experienced developers who write the manual tend to make this kind of "mistakes" then what should we expect from other users? >From the other side if we assume that PHP is OO language then it should be indifferent to the type of object used as array key as long as the object can be hashed and compared to others. IIRC that is the way it works for Python and Java (toString() method). ------------------------------------------------------------------------ [2006-12-07 12:35:30] [EMAIL PROTECTED] Why do you promote bad code in the docs? This code sample is wrong and should be fixed in order to avoid using special types as array keys. ------------------------------------------------------------------------ [2006-12-07 12:27:01] [EMAIL PROTECTED] For resource-dependent array data. Configuration or state information, whatever. For example - http://www.php.net/xml#AEN211968 ------------------------------------------------------------------------ [2006-12-07 10:50:55] [EMAIL PROTECTED] Name at least one reason why do you need to use resource as array keys. >E_STRICT is turned off in PHP5 Yes, it can be turned off, as well as E_WARNING. ------------------------------------------------------------------------ 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/39764 -- Edit this bug report at http://bugs.php.net/?id=39764&edit=1
