Re: [RFC] Using objects as keys

> On Oct 26, 2014, at 9:43 PM, Stas Malyshev <smalyshev@gmail.com> wrote: > > Hi! > >> I’m trying to wrap my head around a real-world use-case with this. >> We have spl_object_hash, which effectively provides a unique hash for > > This hash has nothing to do with object's contents. But imagine number > GMP("42") and imagine you actually want two GMP objects expressing "42" > actually represent the same hash key. Or imagine you want to generate > the key somehow in a way related to object's content and not just a > random number. As I said in the RFC, evidence that so many languages > implement it shows that this use case is quite real. Of course, you can > always default to spl_object_hash, but now you have control over it. Thank you for your clarity. With this new approach, wouldn’t we best be served by renaming/deprecating/removing spl_object_hash? I’m concerned these different approaches will introduce quite a bit of confusion with object hashing. This RFC’s approach gives the user more power to determine what’s best in this case, so I’d lean more towards renaming spl_object_hash to something that reflects getting a unique ID per object (e.g. spl_unique_object_id, etc). > >> an object. If the intent is to provide an opportunity of individual >> classes to decide what their hash is, couldn’t they provide that via >> __toString? I know many frameworks use __toString to build out some >> implementation of an object (Zend form for example), but the point of >> __toString is to provide a string representation of an object. > > This is covered in the RFC, right in the introduction. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/