[RFC] Using objects as keys View as Markdown

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/

Hi!

It seems __toScalar might be a good name, this is what the method
actually does, the engine then coerces to a type suitable for use as a
key, but you can return a double. It might be more forward thinking
therefore to use the name __toScalar, while today we'd only be using
it for this,
__toScalar does not express the fact why we are calling it - to use it
as a key. It's not just a scalar conversion, it's conversion for the
purpose of hashing.

I think that’s the general confusion around this. Generally, the examples provided (Java/Ruby/Python) are based on two things:

1. The value returned is a signed 32-bit (debatable) integer
2. Each hash is calculated based on the properties available (and assigned).

With this in mind, should we not expect, at the very least, and integer on each return? For example:

class Company
{
private $companyId;
private $clientId;

public function __construct($companyId, $clientId)
{
    $this->companyId = (int) $companyId;
    $this->clientId = (int) $clientId;
}

public function __toHash()
{
    return $this->companyId * $this->clientId;
}

}

This is a trivial example, it can be used to define a simple approach for object “uniqueness” and prevent potentially prevent duplicate hashes in a structure.

That said, with PHP’s typeless approach, I understand the case could be made for combining values into a string. To me, it seems more logical and uniform to require an integer - whether signed or unsigned.

Hi!

It seems __toScalar might be a good name, this is what the method
actually does, the engine then coerces to a type suitable for use as a
key, but you can return a double. It might be more forward thinking
therefore to use the name __toScalar, while today we'd only be using
it for this,
__toScalar does not express the fact why we are calling it - to use it
as a key. It's not just a scalar conversion, it's conversion for the
purpose of hashing.

Morning Stas,

True, I was just thinking that the next time we need to represent an
object as a scalar for whatever reason we might end up having to add
another magic method.

It's easy enough to document that __toWhatever is used in the context we
intend to use it in.

Not super bothered about it ... it's obviously a +1 from me whatever the
name.

About restricting to signed/unsigned ints ... this doesn't seem
sensible, the PHP programmer doesn't care about signs, or types.

It makes sense to allow the programmer to return anything we would
currently coerce to a valid key, don't think that needs to change.

Cheers
Joe

Hi!

It seems __toScalar might be a good name, this is what the method
actually does, the engine then coerces to a type suitable for use as a
key, but you can return a double. It might be more forward thinking
therefore to use the name __toScalar, while today we'd only be using
it for this,
__toScalar does not express the fact why we are calling it - to use it
as a key. It's not just a scalar conversion, it's conversion for the
purpose of hashing.

It would also be used by Anthony’s Object Cast To Types (https://wiki.php.net/rfc/object_cast_to_types) RFC if revived, and __toScalar makes more sense there.

Personally, I think __toKey is best. It’s not a hash as such, it’s an equivalent string or integer key value. It fits nicely with __toString, and would fit with other __to* functions like __toInt if that RFC was revived. People would look at __hash and think it’s sql_object_hash, which it isn’t.

--
Andrea Faulds
http://ajf.me/

Am 27.10.2014 08:09 schrieb "Stas Malyshev" smalyshev@sugarcrm.com:

I don't like this, mainly because it blocks a future direct use and
storage
of objects as keys in an array, i.e. what SplObjectStorage does.

It does not. It just allows the objects to control how they are seen
when they are used as keys in regular PHP arrays. That does not prevent
SplObjectStorage or anything else from doing whatever one wants.

I did not mean SplObjectStorage would be affected negatively. Just used it
as the best known example for something that directly supports objects
themselves as keys.

Once your proposal is in the language, you will never, in the future, be
able to add real support for objects as keys, because the semantics is
blocked.

I do understand where your proposal is coming from and what it is trying to
accomplish. But I think, at least, that it should clearly spell out that
any ambition to really support objects as array keys in the base language,
will then be given up.

I personally would say SplObjectStorage probably should respect __hash if
provided, but we can discuss it separately.

I hardly see how that would make sense. SplObjectStorate operates with
object identity as determined by spl_object_hash, right? Changing that to
use your key derivation method, would break that contract. Okay, maybe it
could make sense by adding a second set of attach/detach methods that work
this way when the objects support the new hash method.

Storing objects in the hashtable would really require rewriting the whole
hashtable and would probably be very inefficient as you'd have to call
PHP code each time you compare two objects in the chain.

Right. Somehow python manages to live quite fine with that fact.

Moreover, modifying such objects would probably create havoc.

Right. You don't do that when your object implements hash and eq.

best regards
Patrick

Hi!

I don't like this, mainly because it blocks a future direct use and storage
of objects as keys in an array, i.e. what SplObjectStorage does.

It does not. It just allows the objects to control how they are seen
when they are used as keys in regular PHP arrays. That does not prevent
SplObjectStorage or anything else from doing whatever one wants. I
personally would say SplObjectStorage probably should respect __hash if
provided, but we can discuss it separately.

Do we want to consider to let core use spl_object_hash() if ::__hash()
is not implemented, so objects can always be used as keys?

--
Regards,
Mike

From: Alexander Lisachenko [mailto:lisachenko.it@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.

Maybe something like

interface ArrayKeyConvertable
{
function toArrayKey();
}

Christian

Hi!

As others noted, it also prevents a full-fledged objects-as-key
implementation in the future.
You do realize to have such implementation we'd need to rewrite our
hash
layer completely and also introduce the concept of immutable object,
otherwise changing the object would make the hash completely broken?
Which means it would probably never happen unless PHP engine is
radically rewritten.

Regarding the immutability, I was wondering if it would be possible to treat the hash not as a magic method but a magic property, and then enforce immutability by saying that it could only be written once in a given instance. Generally speaking, a value or model object would be able to write to it in the constructor, and any incidental changes to the object (e.g. to lazy load data fields) would not affect it.

Potentially, the hash implementation would "only" have to store an object reference next to the existing string (or int) key - all the logic of assigning hash buckets, performing equality checks within buckets, etc, would ignore the object and deal with the scalar value in exactly the same way as if it had been implicitly converted as with the current RFC.

If two non-identical objects with the same hash identity were assigned to the same array, there would have to be a decision of which ended up referenced, but as long as it was defined and documented, I can't see either option being a massive problem.

I realise that when it came down to brass tacks, it would be more complex than I'm implying - the memory impact of adding a pointer field on every key might be a problem, for instance - but it would be good not to dismiss it as impossible too quickly, and use up the syntax for a less powerful feature.

In the end it causes issues and brings very little compared to an
explicit call to convert an object to a key.
Same as __toString obviously is useless as you could just call a method
explicitly.

You're putting words into someone else's mouth there. There's a big difference between "brings very little" and "is useless". There are certainly cases where an implicit call would be useful, but they are probably rather rarer than those where the user would want the object back afterwards.

Hi!

As others noted, it also prevents a full-fledged objects-as-key
implementation in the future.
You do realize to have such implementation we'd need to rewrite our hash
layer completely and also introduce the concept of immutable object,
otherwise changing the object would make the hash completely broken?
Which means it would probably never happen unless PHP engine is
radically rewritten.

You argue two things here:

1. it would need a big rewrite of the hash api, so it's unlikely to ever
   happen

It would work almost exactly like string keys, except the hash would be
computed in userland. As such I don't think it is fair to say it would
require a complete rewrite. Non-trivial changes? Sure.

But even if it did require a complete rewrite (and I have no strong
evidence that it wouldn't), recent history has shown that much bigger
rewrites are definitely possible and have happened (e.g. interned strings,
ast, uniform syntax, ...).

2. Hash needs to be stable, so we need the concept of immutable objects

Having non-stable hashes is always an issue, and these requirements would
have to be made clear in the documentation.
Your implementation suffers from the same usability problems if the hash is
not stable (However it is true that it offers a simpler way to "recover").

So I don't think we would need to introduce the concept of immutable
objects, or at least not more than we would with your implementation.

In the end it causes issues and brings very little compared to an
explicit call to convert an object to a key.
Same as __toString obviously is useless as you could just call a method
explicitly.

Let me rephrase:
The small expressivity gain of omitting a call comes at a quite high (IMO)
cost in your implementation. I believe it is not worth it.

Comparing only one side of this equation with another feature makes no
sense.

Best,

Etienne Kneuss