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

Groups > comp.lang.php > #13007

Re: Correlating curl resources to some other object.

Show all headers | View raw

On 2/26/14 1:25 PM, Adam Harvey wrote:
> 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.
Awesome! Thanks for that.

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