Re: intval($resource)

From: Date: Mon, 07 May 2001 04:16:13 +0000
Subject: Re: intval($resource)
References: 1 2  Groups: php.dev 
Request: Send a blank email to php-dev+get-54176@lists.php.net to get a copy of this message
Hello Sterling, On 07-May-01 00:53:37, you wrote: >> >Is there a good reason it needs to use intval() on the resource? To be >> >> Just to overcome a past bug in PHP 4.0.(?). It was making resource values >> inconsistently turn into strings when used as array indexes. A user >> reported a bug on Metabase because of that when it turned out to be a PHP >> bug. The workaround of using intval() made the bug effect go away. >> >This shouldn't be happening (does it still happen for you?) The only time >when a resource should be represented as a string is if you print it out, >in which case that is the proper behaviour. Yes, but until that bug was fixed I felt that I needed to add the workaround because some people were using that version and were complaining as a bug in Metabase. >> >quite honest intval() shouldn't really return a valid value for resources >> >and just by chance it returns the resource id which is probably not a good >> >thing. We can try and look into fixing this problem though. >> >> Resource values should be integers to be consistent with the PHP >> documentation. >> >> >Resource values are internally integers (well, no actually they're >"long"'s but so are PHP's integers, anyyyyyyyway). They're an >abstract type so they should be shown as such, and not have an integer >value. Yes, I know, but that other broke the behaviour. >And the PHP documentation should be consistent with the PHP source, not >the other way around :) Except when the source is buggy! :-) Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --

« previous php.dev (#54176) next »