Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13006

Re: Correlating curl resources to some other object.

Show all headers | View raw

On Wed, 26 Feb 2014 13:52:10 -0500, Jerry Stuckle wrote:
> On 2/26/2014 12:52 PM, Daniel Pitts wrote:
>> On 2/26/14 9:07 AM, Jerry Stuckle wrote:
>>> I don't think there is a guarantee that casting a resource to a string
>>> results in a unique string (although it does seem to work this way
>>> currently).
>> The documentation *does* say it is a unique string.
>>
>> 'Resources are always converted to strings with the structure "Resource
>> id #1", where 1 is the unique number assigned to the resource by PHP at
>> runtime'
>>
>>
> That could be read two ways.  For instance, if a resource is destroyed,
> creating a new resource could have the same number.  It would still
> identify a unique *valid* resource.

To be clear: resource numbers aren't reused within an individual request. 
(At present, they always increase sequentially -- I don't see that 
changing, but also wouldn't want to guarantee it.)

>> Of course, it then says don't rely on that structure. Grr.
>>
>>
> Yes, as I said, I agree it seems to always be a unique value (it
> increments one for each resource created).  But nothing says it will
> remain so, and the doc seems to indicate the opposite.
> 
> Of course, it could also mean don't rely in it being exactly "Resource
> id #1" - but later could be something like "curl resource #1", "mysql
> resource #2", or even just "curl 1" - but still unique.

That's the intention. I agree it was poorly worded.

> The doc is not
> at all clear on this.  I would like to see a clarification on this
> point, for just the reasons you've stated.

I've committed an update to the manual to clarify this. The new wording 
(which will appear over the weekend, assuming no issues with the 
documentation build on Friday) is:

Resources are always converted to strings with the structure "Resource id 
#1", where 1 is the resource number assigned to the resource by PHP at 
runtime. While the exact structure of this string should not be relied on 
and is subject to change, it will always be unique for a given resource 
within the lifetime of a script being executed (ie a Web request or CLI 
process) and won't be reused. To get a resource's type, use the 
get_resource_type() function.

>> I wonder if a feature request to support an "spl_resource_hash" would
>> get any traction.
>>
> I would support some kind of truly unique identifier which could be used
> as a key.  Whether it is an spl_resource_hash or something else makes
> little difference, as long as it's useful.

As noted above, the intention is that casting a resource to a string 
should result in a unique identifier, so a function is unnecessary in 
this case.

Adam

Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 08:54 -0800
  Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 12:07 -0500
    Re: Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 09:52 -0800
      Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 13:52 -0500
        Re: Correlating curl resources to some other object. Adam Harvey <usenet@adamharvey.name> - 2014-02-26 21:25 +0000
          Re: Correlating curl resources to some other object. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-26 13:48 -0800
          Re: Correlating curl resources to some other object. Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-26 17:22 -0500
        OT: getting older/wiser bill <william@TechServSys.com> - 2014-02-27 07:04 -0500
          Re: OT: getting older/wiser Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 08:22 -0500
            Re: OT: getting older/wiser bill <william@TechServSys.com> - 2014-02-27 11:02 -0500
            Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-27 09:11 -0800
              Re: OT: getting older/wiser Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-27 18:52 +0100
              Re: OT: getting older/wiser Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-27 16:20 -0500
              Re: OT: getting older/wiser Allodoxaphobia <knock_yourself_out@example.net> - 2014-02-27 23:56 +0000
                Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-02-28 19:08 -0800
                Re: OT: getting older/wiser Colin Birch <colin@ihatespamrailscans.co.uk> - 2014-03-01 13:37 +0000
                Re: OT: getting older/wiser Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-03-02 12:51 -0800
            Re: OT: getting older/wiser Tim Streater <timstreater@greenbee.net> - 2014-02-27 18:01 +0000

csiph-web