Hi Stas,
Stanislav Malyshev wrote:
> How common is this problem? It looks like an edge case of an edge case
> (converting objects to arrays as such is not a very frequent operation,
> and the reverse is even less frequent) but adds performance hit on the
> common case.
The confusion of string key HashTables with so-called “symtables”
(integer and non-numeric string key HashTables; probably a misnomer)
crops up in a bunch of places. I think (object) and (array) is one of
the more common ones, compared to say, ArrayObject properties and $GLOBALS.
It does make the common case a little slower, it's true, but the the
uncommon case is an important one. You should be able to use arbitrary
string keys in an object or array, rather than having to work around
PHP's brokenness here. I can imagine use cases where this might be a
problem (one that comes to mind is JSON, whose Objects have two
different representations in PHP which you may want to convert between).
More generally, though, it's one less edge case to burden PHP developers
with working around. We shouldn't expect people using PHP to work around
bugs, we should fix them ourselves.
In any case, it's only a small performance hit on an operation that
takes a tiny (~10µs) amount of time anyway. As you said, it's an
infrequent operation. I would be surprised if any application spends
enough of its time converting objects to arrays or vice-versa to see any
performance impact (though I am yet to test this).
>
>> I'm also not sure if this really ought to be an RFC, but I've received
>> little feedback so far, so it can't hurt.
>
> This is a behavior change and a performance hit, so definitely yes, it
> should be RFC.
>
Fair point.
Thanks.
--
Andrea Faulds
https://ajf.me/
