Indexing an array View as Markdown

On Mon, 09 Aug 2010 12:44:03 +0100, mathieu.suen
mathieu.suen@easyflirt.com wrote:

On Fri, 06 Aug 2010 15:33:18 +0100, mathieu.suen
mathieu.suen@easyflirt.com wrote:

For now you can only index an array using a scalar type or a string.
Is there some rfc or work going on to enlarge the possibility so that
it
is possible to have some other object like:

• closure
• object
• etc.

I think the problem with that is how you are going to generate the
hash of arbitrary objects in order to store them in the hash table.
It's not like all PHP objects have a hashCode() method.

IMHO It should.

So the only plausible option would be to attribute the same hash to
all and the test all for equality on an insertion with a new key or in
the worst case scenario for updates and reads.

Since php is not referentially transparent I would rather use identity
unless object can redefine equality.

Well, even if one could overcome the hash problem by using suboptimal
methods like calling __toString (or even use spl_object_hash(), though
we'd be limited to identity) as if they were hashCode() methods, one big
problem remains: the hash tables only store a simple integer (for
numerical indexing) or a char * string (for string indexing) to identify
the key. It would have to be changed to be able to store an object, and
now we'd break a lot of code that expects keys to be either strings or
integers, not to mention the arrays API would be more complicated that it
already is.

SplObjectStorage is a so-so alternative because it only allows identity in
indexing, but you seem to be OK with that.

As to it not working with array functions, you're right, it sucks. In
fact, only array_key_exists and array_walk(_recursive) work with object
(if you can call it "work").

Perhaps one path here is to change the array functions so that if they
receive an object they try to cast it into an array with the cast_object
handler/convert_object_to_type and change the current default
implementation for standard objects, which only handles conversions to
string, to also handle conversions to arrays by traversing the object, if
possible. Not the most efficient thing to do, since it requires copying
everything, but it would be easier than changing the array functions in a
more profound fashion. The "H" parse argument is useless because it tries
to call get_properties (by the way, I don't understand why
convert_to_array(_ex) and convert_to_explicit_type prefer get_properties
to cast_object).

--
Gustavo Lopes

outputs ...

Array
(
[1365443950] => First
[1235256771] => Second
[520059180] => Third
[486985268] => Fourth
)

Well that is not the expected behavior since if you call array_keys you
won't get the object.

Well, "arrays" are implemented as hash tables, hash tables work by
generating a hash to identify a value. Changing this is a big change
(rewrite everything accessing array keys) and you can always do
something like

$array = array(
spl_object_hash($object1) => array('object' => $object1, 'data' => /* .../),
spl_object_hash($object2) => array('object' => $object2, 'data' => / .../),
/...*/
);

The only thing I can imagine is that we add support for objects
implementing ArrayAccess and Traversable (Iterator) on more places.

johannes