Larry Garfield wrote on 30/10/2014 18:07:
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
The desire is for the author of Foo to be able to choose which behaviour
is appropriate for them.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
