Lester Caine wrote on 30/10/2014 16:44:
On 30/10/14 15:06, Rowan Collins wrote:
On 30 October 2014 10:40:10 GMT, Lester Caine <les...@lsces.co.uk> wrote:
On 30/10/14 07:19, Will Fitch wrote:
The magic method is more of a PHP approach while an interface would
be more appropriate. That said, this RFC is a true representation of a
hash vs something like spl_object_hash. That’s what causes user
confusion. spl_object_hash would’ve been better served as a name like
spl_object_id or spl_object_hash_id. Something that indicates
uniqueness regardless of the values of a particular object.
The bit of the jigsaw I'm still missing here is just what the object of
the exercise is?
There are many different use cases for hash keys, and PHP's "array" type is
particularly flexible.
For instance, de-duplicating a list of items ($foo[$x] = $x), or counting
occurrences of each ($foo[$x]++)
In the case of a simple DB model, the primary key value is the obvious choice
for the hash key, but not all objects are as simple as that.
Being able to store the object itself would save having to recreate it from the
key, e.g. looking the ID back up for a DB model, or re-parsing UTF8 for a
UString.
But that statement makes no sense!
Accessing the object is via a handle, so you will always have a pointer
to it. Adding some abstract identifier to describe the pointer is always
going to be secondary to the pointer itself? You need a name to create
an object and creating an array of objects needs keys which can either
just be the PHP default location in the array, or you add a name to that
key in some way. The content of the location in the array is the handle
to the object. It will never be 'the object'?
To look up an object you need to know something about the object and
that is either some subset of the object or an abstract reference which
one looks up in order to access the pointer.
I think you may be confusing two things here - one is storing objects as
the *values* of an associative array, and choosing an appropriate key to
use for each object; the other is using objects (or some representation
of objects) as the *keys* of an associative array, with something
completely different as the value.
Yes, by "the object itself" I mean a pointer to the object, as most
people do when talking colloquially about "passing objects around", etc.
The point is to store a live reference, as opposed to a string or
integer which could, programmatically, be used to look up/recreate the
object.
The use case which came up recently was UString objects, which can
easily be converted to and from plain PHP strings, but would be useful
as keys in their own right. With current PHP you could do $foo[
(string)$u_str ] = $bar; with the proposed RFC, you could do $foo[
$u_str ] = $bar with the same result; but either way, you would still
need to convert *back* to an object in order to use any of the UString
methods in a foreach(), array_walk(), etc.
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
