# [RFC] Using objects as keys

- Thread: https://externals.io/message/78360
- Original archive: https://news-web.php.net/php.internals/78360
- Started by Stas Malyshev on 2014-10-27T01:37:17+00:00
- Messages: 42
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/78360.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #78360 — Stas Malyshev — 2014-10-27T01:37:17+00:00

URL: https://externals.io/message/78360#78360

Hi!

I would like to present to your attention an RFC about using object as keys:

https://wiki.php.net/rfc/objkey

It was discussed in the past on the list:
http://marc.info/?t=141145969600001&r=1&w=2
and I think it makes sense to propose a formal RFC for it. Both the text
and the code in the patch includes bits done by myself and Joe Watkins.
The patch does not cover 100% of cases but should work for most
reasonable scenarios, if something is wrong or you have ideas how to
make it better please tell.

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.

Thanks,
Stas

---

## #78362 — Will Fitch — 2014-10-27T02:23:20+00:00

URL: https://externals.io/message/78360#78362 · In reply to: #78360

> 
> 
> Hi!
> 
> I would like to present to your attention an RFC about using object as keys:
> 
> https://wiki.php.net/rfc/objkey
> 

Hi Stas!

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 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.

I want to say, I’m not at all against this - rather I support it.  I’m just looking for the RFC to provide an example that I and others can relate to.

> It was discussed in the past on the list:
> http://marc.info/?t=141145969600001&r=1&w=2
> and I think it makes sense to propose a formal RFC for it. Both the text
> and the code in the patch includes bits done by myself and Joe Watkins.
> The patch does not cover 100% of cases but should work for most
> reasonable scenarios, if something is wrong or you have ideas how to
> make it better please tell.
> 
> 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.
> 
> Thanks,
> Stas

---

## #78363 — Stas Malyshev — 2014-10-27T02:43:42+00:00

URL: https://externals.io/message/78360#78363 · In reply to: #78362

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.

> 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/

---

## #78364 — Will Fitch — 2014-10-27T03:08:24+00:00

URL: https://externals.io/message/78360#78364 · In reply to: #78363

> 
> 
> Hi!
> 
> > […]
> 
> 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).

> 
> > […]
> 
> This is covered in the RFC, right in the introduction.
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/

---

## #78369 — Joe Watkins — 2014-10-27T05:37:25+00:00

URL: https://externals.io/message/78360#78369 · In reply to: #78360

> Hi!
> 
> I would like to present to your attention an RFC about using object as keys:
> 
> https://wiki.php.net/rfc/objkey
> 
> It was discussed in the past on the list:
> http://marc.info/?t=141145969600001&r=1&w=2
> and I think it makes sense to propose a formal RFC for it. Both the text
> and the code in the patch includes bits done by myself and Joe Watkins.
> The patch does not cover 100% of cases but should work for most
> reasonable scenarios, if something is wrong or you have ideas how to
> make it better please tell.
> 
> 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.
> 
> Thanks,
> Stas
> 

Morning Stas,
	
	Nicely done.
	
	Whether SPL classes, or any other classes, should use the functionality
should be left to another discussion.

	I wonder if it might be feasible to try and define what the contract of
this method is, in the same kind of way as the Java docs do for
Object.hashCode ? We can't have the exact same contract perhaps, but it
might be useful to try to define it at this stage.

	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, if we come up against the
requirement to treat an object as a scalar for anything else, we have
the machinery already and we don't have to add another magic method at
that time.

	Not sure what others think about that ... I liked the name __hash
better than __toKey, I like __toScalar better than those because it
describes what the method is meant to do the best.

Cheers
Joe

---

## #78370 — Stas Malyshev — 2014-10-27T06:36:47+00:00

URL: https://externals.io/message/78360#78370 · In reply to: #78369

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.

---

## #78371 — Will Fitch — 2014-10-27T06:49:17+00:00

URL: https://externals.io/message/78360#78371 · In reply to: #78370

> 
> 
> Hi!
> 
> > […]
> __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.

---

## #78372 — Patrick Schaaf — 2014-10-27T06:53:13+00:00

URL: https://externals.io/message/78360#78372 · In reply to: #78360

Am 27.10.2014 02:37 schrieb "Stas Malyshev" <smalyshev@gmail.com>:
>
> I would like to present to your attention an RFC about using object as
keys:
>
>https://wiki.php.net/rfc/objkey

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 is also badly named, because it does NOT implement objects as keys. It
implements deriving surrogate keys from objects when used in an array key
context.

This is not what other languages do. Python, for example, uses a
combination of __hash__ and __eq__ (or __cmp__), the former to locate the
hash slot, and  the latter to then check for equality when running the hash
chain anchored in that slot. The thing stored as a key, is the real object.
See https://wiki.python.org/moin/DictionaryKeys

best regards
  Patrick

---

## #78373 — Joe Watkins — 2014-10-27T07:04:09+00:00

URL: https://externals.io/message/78360#78373 · In reply to: #78370

> Hi!
> 
> > […]
> __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

---

## #78374 — Stas Malyshev — 2014-10-27T07:09:50+00:00

URL: https://externals.io/message/78360#78374 · In reply to: #78372

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.

> It is also badly named, because it does NOT implement objects as keys. It
> implements deriving surrogate keys from objects when used in an array key
> context.

That's how the objects are used as keys. 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. Moreover, modifying such objects
would probably create havoc. So having an immutable value sounds like
the best solution for the practical use cases.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #78375 — Patrick Schaaf — 2014-10-27T07:22:56+00:00

URL: https://externals.io/message/78360#78375 · In reply to: #78374

Am 27.10.2014 08:09 schrieb "Stas Malyshev" <smalyshev@sugarcrm.com>:
>
> > […]
storage
> > […]
>
> 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

---

## #78376 — Stas Malyshev — 2014-10-27T07:41:01+00:00

URL: https://externals.io/message/78360#78376 · In reply to: #78375

Hi!

> 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.

This implies this support is not "real" and we want some other support.
I don't think I agree with either.

> 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.

Was there ever such an ambition? Does somebody have any idea how to
properly do it and a reason why?

> I hardly see how that would make sense. SplObjectStorate operates with
> object identity as determined by spl_object_hash, right? Changing that

Now, it does, since there's no other option. However, in the future
there may be other options - i.e. objects whose identity is not the same
as their memory address. For example, for an object representing number
(GMP) or string (UString) their identity is their content, not their
memory address. Thus, if you want to use UString as an index, or have an
unique set of strings, spl_object_hash would not be your friend.
Of course, there's always an option of just telling it - e.g. by
providing an option to the ctor.

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

For some definitions of "quite fine", I presume - I can't see how a
hashtable that repeatedly calls user code can be efficient. It probably
isn't.

> Right. You don't do that when your object implements __hash__ and __eq__.

Or, more precisely, you're asked nicely not to do it - because there's
no way to actually ensure it.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #78377 — Joe Watkins — 2014-10-27T07:55:19+00:00

URL: https://externals.io/message/78360#78377 · In reply to: #78376

> Hi!
> 
> > […]
> 
> This implies this support is not "real" and we want some other support.
> I don't think I agree with either.
> 
> > […]
> 
> Was there ever such an ambition? Does somebody have any idea how to
> properly do it and a reason why?
> 
> > […]
> 
> Now, it does, since there's no other option. However, in the future
> there may be other options - i.e. objects whose identity is not the same
> as their memory address. For example, for an object representing number
> (GMP) or string (UString) their identity is their content, not their
> memory address. Thus, if you want to use UString as an index, or have an
> unique set of strings, spl_object_hash would not be your friend.
> Of course, there's always an option of just telling it - e.g. by
> providing an option to the ctor.
> 
> > […]
> 
> For some definitions of "quite fine", I presume - I can't see how a
> hashtable that repeatedly calls user code can be efficient. It probably
> isn't.
> 
> > […]
> 
> Or, more precisely, you're asked nicely not to do it - because there's
> no way to actually ensure it.
> -- 
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> 

Morning,

	As already pointed out by Stas, using objects as array keys would
require a rewrite of the HashTable API, something integral to PHP.

	I'm not sure that is realistic, or possible.

	I think probably, the best way we can support objects as collection
keys is with the introduction of generics, something totally
disconnected from this RFC, that nobody has a working patch for.

Cheers
Joe

---

## #78380 — Michael Wallner — 2014-10-27T08:33:44+00:00

URL: https://externals.io/message/78360#78380 · In reply to: #78374

> Hi!
> 
> > […]
> 
> 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

---

## #78381 — Michael Wallner — 2014-10-27T08:35:02+00:00

URL: https://externals.io/message/78360#78381 · In reply to: #78364

> 
> > […]
> 
> 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).

Actually, I see spl_object_hash($this) the 90% implementation of
__hash(), so how about making it the default for any object?

-- 
Regards,
Mike

---

## #78382 — Lester Caine — 2014-10-27T09:05:37+00:00

URL: https://externals.io/message/78360#78382 · In reply to: #78360

> 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 don't think it's clear from the RFC ...
Is the resulting value intended always to return the same object
independent of what has been done to the object in the mean time? A
fixed 'address' for the physical data when used as an array key?
If that is the case, then __toKey seems more comfortable. To me a hash
is used to establish if the item I am looking at has changed since it
was last accessed. There are two use cases compare the contents are the
same, and access the same object later even if it has been updated.

That said, the EKey value IS intended to identify objects which have
changed since last being accessed ... so you can't win either way?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

## #78383 — Andrea Faulds — 2014-10-27T09:15:00+00:00

URL: https://externals.io/message/78360#78383 · In reply to: #78370

> 
> 
> Hi!
> 
> > […]
> __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/

---

## #78387 — Alexander Lisachenko — 2014-10-27T10:18:02+00:00

URL: https://externals.io/message/78360#78387 · In reply to: #78360

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.

---

## #78392 — Levi Morrison — 2014-10-27T15:54:32+00:00

URL: https://externals.io/message/78360#78392 · In reply to: #78360

> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey

A few points I have against this proposal, as I understand it:

  - It does not store the object, only the result of  `__hash`.
Without the actual object this is not helpful for any use-case I have.

  - Using a method in the object prevents you from hashing on
different members of the objects for different uses. For example,
there is a User object. Most of the time the User::id will be used for
the hash. However, sometimes the hash needs to be on User::username.
If the hashing code is pushed inside the object and call it
automatically then you can't hash on the different values.

In summary 1) the hashing function should be external to the object,
2) should not be invoked magically, and 3) the object needs to be
stored. This can already be done in user-land; here is one such
example that I have created but there are others:
https://github.com/morrisonlevi/Ardent/blob/master/src/HashMap.php

---

## #78393 — Lazare Inepologlou — 2014-10-27T16:15:42+00:00

URL: https://externals.io/message/78360#78393 · In reply to: #78392

2014-10-27 16:54 GMT+01:00 Levi Morrison <levim@php.net>:

> > […]
> keys:
> > […]
>
> A few points I have against this proposal, as I understand it:
>
>   - It does not store the object, only the result of  `__hash`.
> Without the actual object this is not helpful for any use-case I have.
>
>   - Using a method in the object prevents you from hashing on
> different members of the objects for different uses. For example,
> there is a User object. Most of the time the User::id will be used for
> the hash. However, sometimes the hash needs to be on User::username.
> If the hashing code is pushed inside the object and call it
> automatically then you can't hash on the different values.
>
> In summary 1) the hashing function should be external to the object,
> 2) should not be invoked magically, and 3) the object needs to be
> stored. This can already be done in user-land; here is one such
> example that I have created but there are others:
> https://github.com/morrisonlevi/Ardent/blob/master/src/HashMap.php
>
>
Although I don't care very much for the first two points, the third point
is very alarming. Yes, we should have the option to get the objects used as
keys, otherwise the new functionality does not offer much.


Lazare INEPOLOGLOU
Ingénieur Logiciel

---

## #78394 — johannes@schlueters.de — 2014-10-27T17:02:43+00:00

URL: https://externals.io/message/78360#78394 · In reply to: #78381

> Actually, I see spl_object_hash($this) the 90% implementation of
> __hash(), so how about making it the default for any object?

I agree - it might be a good default.

To Will's question: It is not sufficient for all cases. Having a custom
implementation allows the reverse.

 $u = new ustring(".....");
 $a[$u] = 42;
 unset($u);
 foreach ($a as $k => $v) {
   $u = u($k); // u() is a bad name, see other thread for that debate
 }

also spl_object_hash is a unique identify, but given value objects
having them in array_keys might mean that one doesn't want identity but
grouped by value ...

  function get_date_for_item($item) {
      return new DateTime(...);
  }

  foreach ($items as $item) {
    $counts[get_date_for_item($item)]++;
  }

here we create a new Datetime instance for each item, while multiple
items might share the same data. in the loop we're counting distinct
dates not DateTime instances.

johannes

---

## #78396 — Stas Malyshev — 2014-10-27T17:32:34+00:00

URL: https://externals.io/message/78360#78396 · In reply to: #78382

Hi!
> Is the resulting value intended always to return the same object
> independent of what has been done to the object in the mean time? 
That's on you to decide. If you have immutable value object, then yes.
If you have mutable value object (which usually isn't a good idea, but
who knows) then no. If it's not a value object, then probably you don't
want __hash on it at all.

> A fixed 'address' for the physical data when used as an array key? If
> that is the case, then __toKey seems more comfortable. To me a hash is 
I'm fine with __toKey, if that's what seems better to the majority.

---

## #78397 — Etienne Kneuss — 2014-10-27T17:39:26+00:00

URL: https://externals.io/message/78360#78397 · In reply to: #78360

> Hi!
>
> I would like to present to your attention an RFC about using object as
> keys:
>
> https://wiki.php.net/rfc/objkey
>
>

I think it should be made clear that what the target of your RFC is not to
support objects as keys, what you propose instead is an implicit
translation from:

$a[$obj]
to
$a[$obj->__hash()]

This is clearly different. And has at least one major drawback:

The object itself is not in the array, you cannot retrieve it by
foreach($arr as $obj => $v) { }.
=> This is quite counter-intuitive and counter-productive: one would expect
to find the object there, not its "hash".

As others noted, it also prevents a full-fledged objects-as-key
implementation in the future.

In the end it causes issues and brings very little compared to an explicit
call to convert an object to a key.

-1

-- 
Etienne Kneuss

---

## #78398 — Stas Malyshev — 2014-10-27T18:11:48+00:00

URL: https://externals.io/message/78360#78398 · In reply to: #78397

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.
>
> 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.

---

## #78411 — Rowan Collins — 2014-10-28T00:26:25+00:00

URL: https://externals.io/message/78360#78411 · In reply to: #78398

>Hi!
> > […]
>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.

> > […]
>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.

---

Next page: https://externals.io/message/78360.md?page=2