> On Oct 30, 2014, at 6:20 PM, Lester Caine wrote:
>
> On 30/10/14 17:42, Rowan Collins wrote:
>> 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
On 30/10/14 17:42, Rowan Collins wrote:
> 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, y
> On Oct 30, 2014, at 3:28 PM, Andrea Faulds wrote:
>
>
>> On 30 Oct 2014, at 19:51, Will Fitch wrote:
>>
>> My only concern at this point is the default value of the hash. If we were
>> to use spl _object_hash, we could be setting a precedence that a hash must
>> be unique to each object.
> On 30 Oct 2014, at 19:51, Will Fitch wrote:
>
> My only concern at this point is the default value of the hash. If we were to
> use spl _object_hash, we could be setting a precedence that a hash must be
> unique to each object.
In addition to what Stas says above, well, not all objects work
Hi!
> My only concern at this point is the default value of the hash. If we
> were to use spl _object_hash, we could be setting a precedence that a
> hash must be unique to each object.
I don't think there should be any default value. Most objects are not
suitable as keys, only some of them are (
> On Oct 30, 2014, at 1:32 PM, Stas Malyshev wrote:
>
> Hi!
>
>> Put another way, I think a key question here is:
>>
>> class Foo {
>> public $bar;
>> }
>>
>> $a = new Foo;
>> $a->bar = 'baz';
>> $b = new Foo;
>> $b->bar = 'baz';
>>
>> $arr[$a] = true;
>> $arr[$b] = true;
>>
>>
>> Does
Larry Garfield wrote on 30/10/2014 18:07:
On 10/30/14, 2:19 AM, Will Fitch wrote:
On Oct 30, 2014, at 2:13 AM, Christian Stoller
wrote:
From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent:
Monday, October 27, 2014 11:18 AM
Hello, internals!
The name __hash is not final
Hi!
> Put another way, I think a key question here is:
>
> class Foo {
>public $bar;
> }
>
> $a = new Foo;
> $a->bar = 'baz';
> $b = new Foo;
> $b->bar = 'baz';
>
> $arr[$a] = true;
> $arr[$b] = true;
>
>
> Does $arr now contain one value or two?
That depends on the semantics of class Fo
On 10/30/14, 2:19 AM, Will Fitch wrote:
On Oct 30, 2014, at 2:13 AM, Christian Stoller wrote:
From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday,
October 27, 2014 11:18 AM
Hello, internals!
The name __hash is not final, I am open to using __toKey instead or any
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 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 re
On 30/10/14 15:06, Rowan Collins wrote:
> On 30 October 2014 10:40:10 GMT, Lester Caine 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 somet
On 30 October 2014 10:40:10 GMT, Lester Caine 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 us
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 bett
> On Oct 30, 2014, at 2:13 AM, Christian Stoller wrote:
>
>
> From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday,
> October 27, 2014 11:18 AM
>
>> Hello, internals!
>>
>>> The name __hash is not final, I am open to using __toKey instead or any
>>> reasonable alternativ
From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday,
October 27, 2014 11:18 AM
> Hello, internals!
>
>> The name __hash is not final, I am open to using __toKey instead or any
>> reasonable alternative, we may also include a couple of options in the
>> vote if that will be
Hi Stas,
On 27/10/2014 18:39, Etienne Kneuss wrote:
> I think it should be made clear that what the target of your RFC is not to
> support objects as keys, what you propose instead is an implicit
> translation from:
>
> $a[$obj]
> to
> $a[$obj->__hash()]
>
> This is clearly different.
I agree t
On Mon, Oct 27, 2014 at 7:11 PM, Stas Malyshev 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 immutab
On 27 October 2014 18:11:48 GMT, Stas Malyshev 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 ob
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 compl
On Mon, Oct 27, 2014 at 2:37 AM, Stas Malyshev wrote:
> Hi!
>
> I would like to present to your attention an RFC about using object as
> keys:
>
> https://wiki.php.net/rfc/objkey
>
>
I think it should be made clear that what the target of your RFC is not to
support objects as keys, what you prop
Hi!
> Is the resulting value intended always to return the same object
> independent of what has been done to the object in the mean time?
That's on you to decide. If you have immutable value object, then yes.
If you have mutable value object (which usually isn't a good idea, but
who knows) then n
On Mon, 2014-10-27 at 09:35 +0100, Michael Wallner wrote:
> Actually, I see spl_object_hash($this) the 90% implementation of
> __hash(), so how about making it the default for any object?
I agree - it might be a good default.
To Will's question: It is not sufficient for all cases. Having a custom
2014-10-27 16:54 GMT+01:00 Levi Morrison :
> > I would like to present to your attention an RFC about using object as
> keys:
> >
> > https://wiki.php.net/rfc/objkey
>
> A few points I have against this proposal, as I understand it:
>
> - It does not store the object, only the result of `__hash
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
A few points I have against this proposal, as I understand it:
- It does not store the object, only the result of `__hash`.
Without the actual object this is not helpful for any u
Hello, internals!
> The name __hash is not final, I am open to using __toKey instead or any
> reasonable alternative, we may also include a couple of options in the
> vote if that will be a point of disagreement.
I like this idea with custom hash implementation because spl_object_hash()
is not re
> On 27 Oct 2014, at 06:36, Stas Malyshev wrote:
>
> Hi!
>
>> It seems __toScalar might be a good name, this is what the method
>> actually does, the engine then coerces to a type suitable for use as a
>> key, but you can return a double. It might be more forward thinking
>> therefore to use th
On 27/10/14 01:37, Stas Malyshev wrote:
> The name __hash is not final, I am open to using __toKey instead or any
> reasonable alternative, we may also include a couple of options in the
> vote if that will be a point of disagreement.
I don't think it's clear from the RFC ...
Is the resulting valu
On 27/10/14 04:08, Will Fitch wrote:
>
>> On Oct 26, 2014, at 9:43 PM, Stas Malyshev
>> wrote:
>>
>> Hi!
>>
>>> I’m trying to wrap my head around a real-world use-case with
>>> this. We have spl_object_hash, which effectively provides a
>>> unique hash for
>>
>> This hash has nothing to do wit
On 27/10/14 08:09, Stas Malyshev wrote:
> Hi!
>
>> I don't like this, mainly because it blocks a future direct use and storage
>> of objects as keys in an array, i.e. what SplObjectStorage does.
>
> It does not. It just allows the objects to control how they are seen
> when they are used as keys
On Mon, 2014-10-27 at 00:41 -0700, Stas Malyshev wrote:
> Hi!
>
> > Once your proposal is in the language, you will never, in the future, be
> > able to add real support for objects as keys, because the semantics is
> > blocked.
>
> This implies this support is not "real" and we want some other s
Hi!
> Once your proposal is in the language, you will never, in the future, be
> able to add real support for objects as keys, because the semantics is
> blocked.
This implies this support is not "real" and we want some other support.
I don't think I agree with either.
> I do understand where yo
Am 27.10.2014 08:09 schrieb "Stas Malyshev" :
>
> > I don't like this, mainly because it blocks a future direct use and
storage
> > of objects as keys in an array, i.e. what SplObjectStorage does.
>
> It does not. It just allows the objects to control how they are seen
> when they are used as keys
Hi!
> I don't like this, mainly because it blocks a future direct use and storage
> of objects as keys in an array, i.e. what SplObjectStorage does.
It does not. It just allows the objects to control how they are seen
when they are used as keys in regular PHP arrays. That does not prevent
SplObje
On Sun, 2014-10-26 at 23:36 -0700, Stas Malyshev wrote:
> Hi!
>
> > It seems __toScalar might be a good name, this is what the method
> > actually does, the engine then coerces to a type suitable for use as a
> > key, but you can return a double. It might be more forward thinking
> > therefore to
Am 27.10.2014 02:37 schrieb "Stas Malyshev" :
>
> I would like to present to your attention an RFC about using object as
keys:
>
>https://wiki.php.net/rfc/objkey
I don't like this, mainly because it blocks a future direct use and storage
of objects as keys in an array, i.e. what SplObjectStorage d
> On Oct 27, 2014, at 1:36 AM, Stas Malyshev wrote:
>
> Hi!
>
>> It seems __toScalar might be a good name, this is what the method
>> actually does, the engine then coerces to a type suitable for use as a
>> key, but you can return a double. It might be more forward thinking
>> therefore to use
Hi!
> It seems __toScalar might be a good name, this is what the method
> actually does, the engine then coerces to a type suitable for use as a
> key, but you can return a double. It might be more forward thinking
> therefore to use the name __toScalar, while today we'd only be using
> it for thi
On Sun, 2014-10-26 at 18:37 -0700, Stas Malyshev wrote:
> Hi!
>
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
>
> It was discussed in the past on the list:
> http://marc.info/?t=14114596961&r=1&w=2
> and I think it makes se
> On Oct 26, 2014, at 9:43 PM, Stas Malyshev wrote:
>
> Hi!
>
>> I’m trying to wrap my head around a real-world use-case with this.
>> We have spl_object_hash, which effectively provides a unique hash for
>
> This hash has nothing to do with object's contents. But imagine number
> GMP("42") an
Hi!
> I’m trying to wrap my head around a real-world use-case with this.
> We have spl_object_hash, which effectively provides a unique hash for
This hash has nothing to do with object's contents. But imagine number
GMP("42") and imagine you actually want two GMP objects expressing "42"
actually
> On Oct 26, 2014, at 8:37 PM, Stas Malyshev wrote:
>
> Hi!
>
> I would like to present to your attention an RFC about using object as keys:
>
> https://wiki.php.net/rfc/objkey
>
Hi Stas!
I’m trying to wrap my head around a real-world use-case with this. We have
spl_object_hash, which eff
41 matches
Mail list logo
