Invokation on __toString() for object used as array key

Yes, it was removed intentionally (quite a long time ago), like using
resources as array keys, to avoid hard-to-trace bugs for the user. At
least that's the reasoning I can remember.

He doesn't want to add the object as a key, he wants to invoke __toString().

Is there really any harm in adding a IS_OBJECT case to
zend_whatever_add_array_element, and checking if it has a __toString?

It does work if you do an explicit cast to string:

class Foo {
public function __toString()
{
return 'Bar';
}
}

$array = array();
$object = new Foo();
$array[(string) $object] = 'this works';

Cheers,
Andrey.

He doesn't want to add the object as a key, he wants to invoke __toString().

Did I write that?

No, you didn't, sorry.

I just didn't see how an object with an explicit method to convert it
to a string compared to using a resource straight up as a key. If you
were implying the resource would be cast to int, then I get the
comparison.

Does it really make bugs that hard to find? You'd expect the user to
know when they're using this behaviour when they write the code...
well, I would.

I suppose explicit casting removes any ambiguity, we use
$a[(int)$resource] all the time for arrays of sockets and that's
served us fine over the years. Hmm, thinking about it
$a[(string)$object] is a lot clearer than having some magic sort it
out. You're right, I'll retreat now :)

I don't think there is a clear leader on usage of __toString(), for some
it is a debugging feature, for some a "normal" operation.

If people want debugging, there is a method specifically for that, __debugInfo.

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

Hi!

I’m not sure that’d make much sense. The object isn’t the key, the
value the magic method returns is. It would be quite odd to do this:

$someArray = [$my__hashImplementingObject => 1];
var_dump($someArray);

And see something like this, because we’ve called a hash function:

array(1) { ["ec10e5a66e281d105f302cacfb1aaca8"]=> int(0) }

The hash doesn't have to be a nonsensical hex value, it can be something
like "My Object Number 42" if you want to. The difference is that
__toString is for human reading, and it's not always suitable for
hashing purposes. Just read the docs on any of the languages that have
separate hash method - they all have the same argument, there's a
different between printing an object for output and using the object as
a key.

I don’t really see what advantage this has over the normal
__toString. Furthermore, having a special method we use to cast here
that’s used nowhere else seems weird.

That's the point - it's not a cast. It's an operation that requires
object's identity. Again, given that so many languages have it, I don't
think it's really that weird. I think it's pretty natural.

Now, if we were to add actual object key support, that I might like.
But if we’re going to keep with just integers and strings, I’d much
prefer to just support __toString here. I think users are smart
enough to understand that PHP arrays only have string or int keys, so
it casts to a string.

The problem is you mix here two completely different domains. On one
hand, you may want the object to have text representation for output
purposes - say, XML object would have XML output as it's string rep. On
other hand, I don't think you want to use 100K XML as a key, because
using as a key is a completely different issue. Converting to string is
a hack that mixes two different problems into one method, and that's why
it will lead to problems. The solution for this problem is known and
widely used - have a separate hash method. With PHP, you can actually
have a luxury of using a human-readable keys while still keeping them
nice and clean and independent from string representation. And if you
want maximum efficiency, you could switch to ints instead.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

Am 24.09.2014 22:01 schrieb "Andrea Faulds" ajf@ajf.me:

Now, if we were to add actual object key support, that I might like. But
if we’re going to keep with just integers and strings, I’d much prefer to
just support __toString here. I think users are smart enough to understand
that PHP arrays only have string or int keys, so it casts to a string.

Once you do that - automatically use __toString on objects used as keys,
the way to full object key support in the future, is completely blocked,
because BC.

I'd much more like to see full object key support, with spl_object_hash or
a magic __hash() method only used to determine hash slot position
internally.

best regards
Patrick