> On Oct 26, 2014, at 9:43 PM, Stas Malyshev <smalys...@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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
