On 10/30/14, 2:19 AM, Will Fitch wrote:
On Oct 30, 2014, at 2:13 AM, Christian Stoller <stol...@leonex.de> wrote:
From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday,
October 27, 2014 11:18 AM
Hello, internals!
The name __hash is not final, I am open to using __toKey instead or any
reasonable alternative, we may also include a couple of options in the
vote if that will be a point of disagreement.
I like this idea with custom hash implementation because spl_object_hash()
is not reliable when objects are quickly created/destroyed, so hashes can
be the same for several different objects. However, will it be better to
introduce an interface for that? For example, Hashable can be a good name
(like Traversable one). Default implementation then can be a simple trait
that will be added later to the concrete class.
I like the idea introducing an interface for this functionality, instead
of adding a further magic method. But I think anything like "hash" or
"hashable" is confusing for users.
The magic method is more of a PHP approach while an interface would be more
appropriate. That said, this RFC is a true representation of a hash vs
something like spl_object_hash. That’s what causes user confusion.
spl_object_hash would’ve been better served as a name like spl_object_id or
spl_object_hash_id. Something that indicates uniqueness regardless of the
values of a particular object.
Put another way, I think a key question here is:
class Foo {
public $bar;
}
$a = new Foo;
$a->bar = 'baz';
$b = new Foo;
$b->bar = 'baz';
$arr[$a] = true;
$arr[$b] = true;
Does $arr now contain one value or two?
If the desire is for it to contain 2, then spl_object_hash($a) already
has that covered, I think.
If the desire is for it to contain 1, then the proposal sounds like a
way to normalize Foo::stringifiedValueObjectEquivalent().
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
