# New function proposal: spl_object_id - Thread: https://externals.io/message/42300 - Original archive: https://news-web.php.net/php.internals/42300 - Started by Guilherme Blanco on 2008-12-17T17:31:19+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #42300 — Guilherme Blanco — 2008-12-17T17:31:19+00:00 URL: https://externals.io/message/42300#42300 Hi, I spoke with some devs yesterday about spl_object_hash performance and alternatives to solve it. Seems that md5 applied inside it is the responsable for that. After some tips from Lars, we came with a patch (at the bottom of this email). The new proposed function is already being used in Doctrine 2.0 (to be released in 2009), which takes advantages of new features of 5.3. During our tests, everything passed without conflicting or leading to unpredictable values. The performance did not increase too much as I expected, but it reached to a good value for me now. It's as fast as calculating the spl_object_hash once and do a method call, which is an interesting value. It seems that Marcus controls the commit access to SPL. So I'm turning the conversation async, since I cannot find him online at IRC. So, can anyone review the patch, comment it and commit if approved? Thanks in advance, Index: ext/spl/php_spl.c =================================================================== RCS file: /repository/php-src/ext/spl/php_spl.c,v retrieving revision 1.52.2.28.2.17.2.33 diff -u -r1.52.2.28.2.17.2.33 php_spl.c --- ext/spl/php_spl.c 30 Nov 2008 00:23:06 -0000 1.52.2.28.2.17.2.33 +++ ext/spl/php_spl.c 16 Dec 2008 19:05:05 -0000 @@ -682,6 +682,23 @@ } /* }}} */ +/* {{{ proto string spl_object_id(object obc) + Return id for the given object */ +PHP_FUNCTION(spl_object_id) +{ + zval *obj; + char *string; + int len; + + if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == FAILURE) { + return; + } + + len = spprintf(&string, 0, "%p%d", Z_OBJ_HT_P(obj), Z_OBJ_HANDLE_P(obj)); + RETURN_STRING(string, 1); +} +/* }}} */ + PHPAPI void php_spl_object_hash(zval *obj, char *md5str TSRMLS_DC) /* {{{*/ { int len; @@ -798,6 +815,10 @@ ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_hash, 0, 0, 1) ZEND_ARG_INFO(0, obj) ZEND_END_ARG_INFO() + +ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_id, 0, 0, 1) + ZEND_ARG_INFO(0, obj) +ZEND_END_ARG_INFO() /* }}} */ /* {{{ spl_functions @@ -813,6 +834,7 @@ PHP_FE(class_parents, arginfo_class_parents) PHP_FE(class_implements, arginfo_class_implements) PHP_FE(spl_object_hash, arginfo_spl_object_hash) + PHP_FE(spl_object_id, arginfo_spl_object_id) #ifdef SPL_ITERATORS_H PHP_FE(iterator_to_array, arginfo_iterator_to_array) PHP_FE(iterator_count, arginfo_iterator) -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil --- ## #42301 — Lars Strojny — 2008-12-17T18:29:50+00:00 URL: https://externals.io/message/42300#42301 · In reply to: #42300 Hi Guilherme, thanks for moving the discussion to the list. Am Mittwoch, den 17.12.2008, 15:31 -0200 schrieb Guilherme Blanco: [...] > It seems that Marcus controls the commit access to SPL. So I'm turning > the conversation async, since I cannot find him online at IRC. > So, can anyone review the patch, comment it and commit if approved? Just for clarification, it is not about access, but about maintenance. So if Marcus gives his go, we can happily apply the patch and add a few tests (something you could start preparing now). cu, Lars --- ## #42302 — Andi Gutmans — 2008-12-17T18:33:11+00:00 URL: https://externals.io/message/42300#42302 · In reply to: #42300 Shouldn't you be using RETURN_STRINGL with length and dup=0? Andi > -----Original Message----- > From: Guilherme Blanco [mailto:guilhermeblanco@gmail.com] > Sent: Wednesday, December 17, 2008 9:31 AM > To: internals Mailing List > Subject: [PHP-DEV] New function proposal: spl_object_id > > Hi, > > I spoke with some devs yesterday about spl_object_hash performance and > alternatives to solve it. > Seems that md5 applied inside it is the responsable for that. > > After some tips from Lars, we came with a patch (at the bottom of this email). > The new proposed function is already being used in Doctrine 2.0 (to be > released in 2009), which takes advantages of new features of 5.3. > During our tests, everything passed without conflicting or leading to > unpredictable values. > The performance did not increase too much as I expected, but it > reached to a good value for me now. It's as fast as calculating the > spl_object_hash once and do a method call, which is an interesting > value. > > It seems that Marcus controls the commit access to SPL. So I'm turning > the conversation async, since I cannot find him online at IRC. > So, can anyone review the patch, comment it and commit if approved? > > > Thanks in advance, > > > > > Index: ext/spl/php_spl.c > =================================================================== > RCS file: /repository/php-src/ext/spl/php_spl.c,v > retrieving revision 1.52.2.28.2.17.2.33 > diff -u -r1.52.2.28.2.17.2.33 php_spl.c > --- ext/spl/php_spl.c 30 Nov 2008 00:23:06 -0000 1.52.2.28.2.17.2.33 > +++ ext/spl/php_spl.c 16 Dec 2008 19:05:05 -0000 > @@ -682,6 +682,23 @@ > } > /* }}} */ > > +/* {{{ proto string spl_object_id(object obc) > + Return id for the given object */ > +PHP_FUNCTION(spl_object_id) > +{ > + zval *obj; > + char *string; > + int len; > + > + if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "o", &obj) == > FAILURE) { > + return; > + } > + > + len = spprintf(&string, 0, "%p%d", Z_OBJ_HT_P(obj), > Z_OBJ_HANDLE_P(obj)); > + RETURN_STRING(string, 1); > +} > +/* }}} */ > + > PHPAPI void php_spl_object_hash(zval *obj, char *md5str TSRMLS_DC) /* {{{*/ > { > int len; > @@ -798,6 +815,10 @@ > ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_hash, 0, 0, 1) > ZEND_ARG_INFO(0, obj) > ZEND_END_ARG_INFO() > + > +ZEND_BEGIN_ARG_INFO_EX(arginfo_spl_object_id, 0, 0, 1) > + ZEND_ARG_INFO(0, obj) > +ZEND_END_ARG_INFO() > /* }}} */ > > /* {{{ spl_functions > @@ -813,6 +834,7 @@ > PHP_FE(class_parents, arginfo_class_parents) > PHP_FE(class_implements, arginfo_class_implements) > PHP_FE(spl_object_hash, arginfo_spl_object_hash) > + PHP_FE(spl_object_id, arginfo_spl_object_id) > #ifdef SPL_ITERATORS_H > PHP_FE(iterator_to_array, arginfo_iterator_to_array) > PHP_FE(iterator_count, arginfo_iterator) > > > > > -- > Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > URL: http://blog.bisna.com > São Paulo - SP/Brazil --- ## #42303 — Etienne Kneuss — 2008-12-17T18:59:01+00:00 URL: https://externals.io/message/42300#42303 · In reply to: #42301 Hello, > Hi Guilherme, > > thanks for moving the discussion to the list. > > Am Mittwoch, den 17.12.2008, 15:31 -0200 schrieb Guilherme Blanco: > [...] > > […] > > Just for clarification, it is not about access, but about maintenance. > So if Marcus gives his go, we can happily apply the patch and add a few > tests (something you could start preparing now). > > cu, Lars > Last time I checked with Marcus, there were concerns about disclosing a valid pointer to the user. I'd be happy to see a use-case where this information is really needed heavily. The only real usecase of heavy usages seems to be to implement sets of objects. but splObjectStorage is here for that precise use-case... Regards -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42305 — Lars Strojny — 2008-12-17T19:54:45+00:00 URL: https://externals.io/message/42300#42305 · In reply to: #42302 Hi Andi, Am Mittwoch, den 17.12.2008, 10:33 -0800 schrieb Andi Gutmans: > Shouldn't you be using RETURN_STRINGL with length and dup=0? Yes, the more recent implementation does exactly that :) cu, Lars --- ## #42307 — Marcus Boerger — 2008-12-17T21:19:11+00:00 URL: https://externals.io/message/42300#42307 · In reply to: #42303 Hello Etienne, Wednesday, December 17, 2008, 7:59:01 PM, you wrote: > Hello, > > > […] > Last time I checked with Marcus, there were concerns about disclosing > a valid pointer to the user. > I'd be happy to see a use-case where this information is really needed > heavily. The only real usecase of heavy usages seems to be to > implement sets of objects. but splObjectStorage is here for that > precise use-case... Correct in all Etienne. The patch might be a tiny bit faster but exposes valid pointers which is extremely bad and also allows other bad things. That was the only reason I used md5 hashin. What I needed was something that is really unique per object (object pointer or id plus pointer to handler table). Since `spl_object_hash()` does not say how it creates the hash it should be fine change the way it does it. Since in a new session the hashes are of no more use we can even do that in any new version. However I must still insist on not exposing any valid information. Last but not least. In your code you know the maximum length of the extression, so you can allocate the string and snprintf into it. Even faster is to do a hexdump into a preallocated string. For the size use: char* hash = (char*)safe_emalloc(sizeof(void*), 2, 1); Now the dump of the two pointers. This approach should make it a bit faster for you. Something that might work is to create a random 128 bit hash key that is xored onto the hash created from the two pointers. This hash key can be allocated for each session the first time the function will be used. If you do that I am more than happy to accept that as a replacement for current `spl_object_hash()`. marcus > Regards > -- > Etienne Kneuss > http://www.colder.ch > Men never do evil so completely and cheerfully as > when they do it from a religious conviction. > -- Pascal Best regards, Marcus --- ## #42707 — Guilherme Blanco — 2009-01-19T16:39:58+00:00 URL: https://externals.io/message/42300#42707 · In reply to: #42307 Ok, We'll use this method inside Doctrine ORM version 2.0, scheduled to be released on September 1st, 2009. One main location where we are already using it is during Hydration process. The process of grab a DB tuple and convert it into an Object graph. Here is the usage. Each Object of the graph is a Value Object (http://en.wikipedia.org/wiki/Value_object). So it does not have any other mapping else than to-be persisted ones. No internal method implementation is needed. All Active Record like actions are controlled by EntityManager. Based on that, we have a ClassMetadata that is catch based on class name (currently based on spl_object_id, but it's too resources expensive and I'll change that). When we get the DB tuple, we need to find the exact ClassMetadata of that item and apply the specific DB/PHP type castings for example. Also there's a property attribution. Property attribution is thanks to new Reflection API. We store the ReflectionProperty of each field and assign it when we have its definition. Another location where we rely spl_object_id is inside UnitOfWork (http://martinfowler.com/eaaCatalog/unitOfWork.html). We generate a mapping of each Entity/Collection to be persisted/updated/deleted. We define the order of appliance of these things based on first the generated OID (spl_object_id return) and later by Topological Sorting (http://en.wikipedia.org/wiki/Topological_sorting). Finally, we start the transaction and the statements. The point is that we may have being doing a huge hydration with a lots of relationed objects. We may be dealing with a webpage that fetches for more than 5000 records with even more associations. All of that runtime. So I have to say performance is something VERY important for us. Why will we not use SplStorage? Because it'll be used on different places and should share the same OID. Including couple of this component is not a viable idea since it'll go to a more memory expensive solution, which we're trying to optimize a lot and also will force us to include another get call (through method call), which will fall into an even slower implementation. Here are two files that we have being using spl_object_id (changed now to spl_object_hash, since the idea is to update it with Marcus' suggestions): Object Driver for Hydration: http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectDriver.php UnitOfWork for Persistance: http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/UnitOfWork.php Short version: Because we want a fast, easy way to associate information (temporarily) with an object. Most of the time we use the object id/hash as a key in an array. Basically, spl_object_hash is fine, it would just be nice if it could be improved in speed. It'll take me some time to dig into PHP source to try to implement it. I'm not a C developer and there're more than 4 years I didn't touch a single line o C code. Also I can read PHP source, but I'm not able to create it. I already spoke with Felipe which will help me solving questions about src, but I cannot guarantee I'll be able to do the job. Regards, > Hello Etienne, > > Wednesday, December 17, 2008, 7:59:01 PM, you wrote: > > > […] > > > […] > > > […] > > Correct in all Etienne. The patch might be a tiny bit faster but exposes > valid pointers which is extremely bad and also allows other bad things. > That was the only reason I used md5 hashin. What I needed was something > that is really unique per object (object pointer or id plus pointer to > handler table). Since `spl_object_hash()` does not say how it creates the > hash it should be fine change the way it does it. Since in a new session > the hashes are of no more use we can even do that in any new version. > However I must still insist on not exposing any valid information. > > Last but not least. In your code you know the maximum length of the > extression, so you can allocate the string and snprintf into it. Even > faster is to do a hexdump into a preallocated string. For the size use: > char* hash = (char*)safe_emalloc(sizeof(void*), 2, 1); > Now the dump of the two pointers. > This approach should make it a bit faster for you. Something that might > work is to create a random 128 bit hash key that is xored onto the hash > created from the two pointers. This hash key can be allocated for each > session the first time the function will be used. If you do that I am more > than happy to accept that as a replacement for current `spl_object_hash()`. > > marcus > > > […] > > > > […] > > > […] > > > > > Best regards, > Marcus > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil --- ## #42721 — Etienne Kneuss — 2009-01-20T09:28:03+00:00 URL: https://externals.io/message/42300#42721 · In reply to: #42707 Hello, We already had that discussion in private, but here is a on-list summary: On Mon, Jan 19, 2009 at 5:39 PM, Guilherme Blanco wrote: > Ok, > > We'll use this method inside Doctrine ORM version 2.0, scheduled to be > released on September 1st, 2009. > > One main location where we are already using it is during Hydration process. > The process of grab a DB tuple and convert it into an Object graph. > Here is the usage. > > Each Object of the graph is a Value Object > (http://en.wikipedia.org/wiki/Value_object). So it does not have any > other mapping else than to-be persisted ones. No internal method > implementation is needed. All Active Record like actions are > controlled by EntityManager. > > Based on that, we have a ClassMetadata that is catch based on class > name (currently based on spl_object_id, but it's too resources > expensive and I'll change that). When we get the DB tuple, we need to > find the exact ClassMetadata of that item and apply the specific > DB/PHP type castings for example. Also there's a property attribution. > Property attribution is thanks to new Reflection API. We store the > ReflectionProperty of each field and assign it when we have its > definition. > > Another location where we rely spl_object_id is inside UnitOfWork > (http://martinfowler.com/eaaCatalog/unitOfWork.html). We generate a > mapping of each Entity/Collection to be persisted/updated/deleted. We > define the order of appliance of these things based on first the > generated OID (spl_object_id return) and later by Topological Sorting > (http://en.wikipedia.org/wiki/Topological_sorting). Finally, we start > the transaction and the statements. > > The point is that we may have being doing a huge hydration with a lots > of relationed objects. We may be dealing with a webpage that fetches > for more than 5000 records with even more associations. All of that > runtime. So I have to say performance is something VERY important for > us. > > Why will we not use SplStorage? > Because it'll be used on different places and should share the same > OID. Including couple of this component is not a viable idea since > it'll go to a more memory expensive solution, which we're trying to > optimize a lot and also will force us to include another get call > (through method call), which will fall into an even slower > implementation. > > Here are two files that we have being using spl_object_id (changed now > to spl_object_hash, since the idea is to update it with Marcus' > suggestions): > Object Driver for Hydration: > http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/Internal/Hydration/ObjectDriver.php > UnitOfWork for Persistance: > http://trac.doctrine-project.org/browser/trunk/lib/Doctrine/ORM/UnitOfWork.php > > > > Short version: Because we want a fast, easy way to associate > information (temporarily) with an object. Most of the time we use the > object id/hash as a key in an array. Basically, spl_object_hash is > fine, it would just be nice if it could be improved in speed. > All those use cases are related to a [object => data] map, which can be solved by SplObjectStorage: $storage = new SplObjectStorage; $storage[$obj1] = $data; ... var_dump($storage[$obj1]); ... There were three concerns: 1) Speed: the main ground for spl_object_id is speed. => Splobjectstorage is faster than an array with spl_object_hash (and can be made even faster). 2) $storage[$obj1]['index'] = 2; This is sadly a limitation of ArrayAccess => It can be solved either by doing get+change+set, or using an ArrayObject instead of an array. 3) Memory: Since the object itself will be referenced in the storage, you'll have to delete it from every maps in order for GC to do its work. => This is a security, indeed, an object stays unique as long as it exists: $a = new StdClass; $h1 = spl_object_hash($a); unset($a); $b = new StdClass; $h2 = spl_object_hash($b) var_dump($h1===$h2); // bool(true) Conclusion: If you clean your objects without properly taking care of the metadata stored in the array indexed by object_id, you'll get unexpected results anyway. So far it looks like SplObjectStorage is fine with those use cases. If somebody has a practical (with code) use case in which SplObjectStorage can't be sanely used and where spl_object_id is the only solution, please shoot. > > > It'll take me some time to dig into PHP source to try to implement it. > I'm not a C developer and there're more than 4 years I didn't touch a > single line o C code. Also I can read PHP source, but I'm not able to > create it. > I already spoke with Felipe which will help me solving questions about > src, but I cannot guarantee I'll be able to do the job. > > > Regards, > > > > […] > > > > -- > Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > URL: http://blog.bisna.com > São Paulo - SP/Brazil > Regards, -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42722 — Stan Vassilev | FM — 2009-01-20T10:47:26+00:00 URL: https://externals.io/message/42300#42722 · In reply to: #42721 Hi, I had a talk with Marcus, and he has agreed on this proposed solution: 1) SPL generates a pseudo-random session id/mask (for the current request, do not confuse with $_SESSION), which consists of 32 random bytes/characters. 2) The object is and the handler pointer are used to create a unique identifier for the object, by padding each pointer to 16 bytes and joining them together. 3) The resulting byte sequence is XOR-red with the session mask so the object id/handler are not retrievable in userland, and the resulting sequence/string is returned. This is better than spl_object_hash for two reasons: 1) no printf of numbers, no expensive md5 hashing, no hex conversion. 2) no possible collisions Drawbacks: 1) might generate some non-printable chars after xor (but this wouldn't matter for operation). The idea above can be tweaked to solve this. The "32-bit string" format is to preserve compatibility with spl_object_hash, so it can replace it, instead of introducing a new similar function. I've had no time to look further into this, but Marcus seems to like the basic idea, so feel welcome... Regards, Stan Vassilev --- ## #42724 — Etienne Kneuss — 2009-01-20T12:26:53+00:00 URL: https://externals.io/message/42300#42724 · In reply to: #42722 Hello, On Tue, Jan 20, 2009 at 11:47 AM, Stan Vassilev | FM wrote: > > Hi, > > I had a talk with Marcus, and he has agreed on this proposed solution: > > 1) SPL generates a pseudo-random session id/mask (for the current request, > do not confuse with $_SESSION), which consists of 32 random > bytes/characters. > 2) The object is and the handler pointer are used to create a unique > identifier for the object, by padding each pointer to 16 bytes and joining > them together. > 3) The resulting byte sequence is XOR-red with the session mask so the > object id/handler are not retrievable in userland, and the resulting > sequence/string is returned. > > This is better than spl_object_hash for two reasons: > > 1) no printf of numbers, no expensive md5 hashing, no hex conversion. > 2) no possible collisions > > Drawbacks: > > 1) might generate some non-printable chars after xor (but this wouldn't > matter for operation). The idea above can be tweaked to solve this. > > The "32-bit string" format is to preserve compatibility with > spl_object_hash, so it can replace it, instead of introducing a new similar > function. > > I've had no time to look further into this, but Marcus seems to like the > basic idea, so feel welcome... Could you please provide an example, with code, in which this function would be necessary ? (i.e. where you can't use SplObjeccctStorage) Thanks. > > Regards, > Stan Vassilev > > -- > > > > > > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42725 — Hannes Magnusson — 2009-01-20T12:41:51+00:00 URL: https://externals.io/message/42300#42725 · In reply to: #42724 > > Could you please provide an example, with code, in which this function > would be necessary ? (i.e. where you can't use SplObjeccctStorage) Why? As far as i understand, the issue is that `spl_object_hash()` is slow and people want a faster alternatives. Although the initial reason for the faster alternative was to do maintain some classmap for a "random" PHP project, this has nothing to do with the fact `spl_object_hash()` is slow, especially compared to the proposed `spl_object_id()` function. Now, your "workarounds" using SplObjectStorage may work for the previous mentioned usecases - but how the frick is anyone supposed know to know about the wonders of SplObjectStorage? The doxygen is very confusing and definetly does not replace real documentation - plus it doesn't mention the things you are referring too (object => data map) or any of the other 5.3 features. -Hannes --- ## #42726 — Guilherme Blanco — 2009-01-20T12:45:27+00:00 URL: https://externals.io/message/42300#42726 · In reply to: #42724 Hi, It seems SplObjectStorage will solve my issue. We already spoke on pvt about how to handle things correctly too. Although this solve my issue, the point that Stan highlighted is valid. You may not find a good place where to use it, but spl_object_hash is there and it has drawbacks. Just naming collision possibility is enough to convince me about function change, even though I can't imagine a usage of it now. If none can find a usage, so we can drop spl_object_hash, right? If you don't agree, then we need some change to make it faster and non-collision proof. Regards, > Hello, > > On Tue, Jan 20, 2009 at 11:47 AM, Stan Vassilev | FM > wrote: > > […] > > Could you please provide an example, with code, in which this function > would be necessary ? (i.e. where you can't use SplObjeccctStorage) > > Thanks. > > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch > > Men never do evil so completely and cheerfully as > when they do it from a religious conviction. > -- Pascal > > -- > > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil --- ## #42727 — Etienne Kneuss — 2009-01-20T13:20:31+00:00 URL: https://externals.io/message/42300#42727 · In reply to: #42725 Hello, On Tue, Jan 20, 2009 at 1:41 PM, Hannes Magnusson wrote: > > > […] > > Why? > > As far as i understand, the issue is that `spl_object_hash()` is slow > and people want a faster alternatives. > Although the initial reason for the faster alternative was to do > maintain some classmap for a "random" PHP project, this has nothing to > do with the fact `spl_object_hash()` is slow, especially compared to the > proposed `spl_object_id()` function. People that need a faster alternative usually need it to have an efficient object hash map. So far all the use cases where a faster spl_object_hash was needed is to do exactly that. Since this is already possible, the need for spl_object_id is questionable. If there is a clear need for it, I'll be happy to implement it myself. > > Now, your "workarounds" using SplObjectStorage may work for the > previous mentioned usecases - but how the frick is anyone supposed > know to know about the wonders of SplObjectStorage? > The doxygen is very confusing and definetly does not replace real > documentation - plus it doesn't mention the things you are referring > too (object => data map) or any of the other 5.3 features. So, since documentation is currently bad, we should implement some additional functions to do the same? Sorry, but your SPL documentation vendetta is irrelevant to the question at hand. > > -Hannes > > > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42728 — Etienne Kneuss — 2009-01-20T13:23:51+00:00 URL: https://externals.io/message/42300#42728 · In reply to: #42726 Hello, On Tue, Jan 20, 2009 at 1:45 PM, Guilherme Blanco wrote: > Hi, > > It seems SplObjectStorage will solve my issue. > We already spoke on pvt about how to handle things correctly too. > > Although this solve my issue, the point that Stan highlighted is > valid. You may not find a good place where to use it, but > spl_object_hash is there and it has drawbacks. Just naming collision > possibility is enough to convince me about function change, even > though I can't imagine a usage of it now. > > If none can find a usage, so we can drop spl_object_hash, right? This is not possible for BC reasons. Also, changing it internally so it no longer returns a md5 hash might be doable but it will have some BC effects as well. If those effects are considered to be harmless, then sure, I'd be happy to make that function faster by implementing what was discussed before. > If > you don't agree, then we need some change to make it faster and > non-collision proof. > > > Regards, Regards, > > > > […] > > > > -- > Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > URL: http://blog.bisna.com > São Paulo - SP/Brazil > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42729 — Guilherme Blanco — 2009-01-20T13:23:55+00:00 URL: https://externals.io/message/42300#42729 · In reply to: #42727 Etienne, We all already considered to not implement spl_object_id as long as spl_object_hash is optimized. Regards, > Hello, > > On Tue, Jan 20, 2009 at 1:41 PM, Hannes Magnusson > wrote: > > […] > > People that need a faster alternative usually need it to have an > efficient object hash map. So far all the use cases where a faster > spl_object_hash was needed is to do exactly that. Since this is > already possible, the need for spl_object_id is questionable. If there > is a clear need for it, I'll be happy to implement it myself. > > > […] > > So, since documentation is currently bad, we should implement some > additional functions to do the same? > Sorry, but your SPL documentation vendetta is irrelevant to the > question at hand. > > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch > > Men never do evil so completely and cheerfully as > when they do it from a religious conviction. > -- Pascal > > -- > > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil --- ## #42730 — Etienne Kneuss — 2009-01-20T13:38:32+00:00 URL: https://externals.io/message/42300#42730 · In reply to: #42729 Hello, On Tue, Jan 20, 2009 at 2:23 PM, Guilherme Blanco wrote: > Etienne, > > We all already considered to not implement spl_object_id as long as > spl_object_hash is optimized. Ok then, I'll provide a patch to improve spl_object_hash's performance, which will also change it's output. Documentation will also need to be updated so that people are aware that most of the time SplObjectStorage will be a better alternative. Regards, > > Regards, > > > > […] > > > > -- > Guilherme Blanco - Web Developer > CBC - Certified Bindows Consultant > Cell Phone: +55 (16) 9215-8480 > MSN: guilhermeblanco@hotmail.com > URL: http://blog.bisna.com > São Paulo - SP/Brazil > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal --- ## #42794 — Etienne Kneuss — 2009-01-23T01:33:10+00:00 URL: https://externals.io/message/42300#42794 · In reply to: #42730 Hello, > Hello, > > On Tue, Jan 20, 2009 at 2:23 PM, Guilherme Blanco > wrote: > > […] > > Ok then, I'll provide a patch to improve spl_object_hash's > performance, which will also change it's output. > Documentation will also need to be updated so that people are aware > that most of the time SplObjectStorage will be a better alternative. > Here is the mentioned patches: http://patches.colder.ch/php-src/spl_object_hash-5_3.patch?markup http://patches.colder.ch/php-src/spl_object_hash-HEAD.patch?markup If nobody objects, I'll commit them Sunday. Regards, > Regards, > > > […] > > > > -- > Etienne Kneuss > http://www.colder.ch > > Men never do evil so completely and cheerfully as > when they do it from a religious conviction. > -- Pascal > -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal