On Mon, Oct 27, 2014 at 7:11 PM, Stas Malyshev <smalys...@gmail.com> wrote:
> 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
