On 16/12/2014 09:34, Stanislav Malyshev wrote:
I'd like to initiate a vote on "objects as keys" RFC:
https://wiki.php.net/rfc/objkey
Hi,
After discussing this RFC with other members of AFUP, we would probably
be +1 on the idea of being able to really use objects as keys.
But, considering thi
Lester Caine wrote:
> On 18/12/14 09:03, Stanislav Malyshev wrote:
>>> Luckily, we have SplObjectStorage, which maybe makes that rather less
urgent as well.
>> SplObjectStorage doesn't do this - SplObjectStorage uses objects'
>> identity, which means two GMP(1)'s are different objects.
>
> S
On 18/12/14 09:03, Stanislav Malyshev wrote:
>> Luckily, we have SplObjectStorage, which maybe makes that rather less
>> > urgent as well.
> SplObjectStorage doesn't do this - SplObjectStorage uses objects'
> identity, which means two GMP(1)'s are different objects.
Silly question time again ...
Hi!
> Luckily, we have SplObjectStorage, which maybe makes that rather less
> urgent as well.
SplObjectStorage doesn't do this - SplObjectStorage uses objects'
identity, which means two GMP(1)'s are different objects.
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Develop
Hi,
I originally considered you could retrieve the object key, but if it is not
possible by this RFC, I will switch my vote to no.
By storing hash one way it introduces a huge wtf to the language.
Cheers,
On Dec 17, 2014 8:40 PM, "Rowan Collins" wrote:
> On 17/12/2014 22:05, Rowan Collins wrot
>> Programmable hashes of objects should be external to the object anyway
>> because eventually someone wants to store the same object in a
>> different way in two different structures.
>
> That is the requirement that no language I can think of implements -
> Java, Python, Ruby, C# all have progra
On 17/12/2014 22:05, Rowan Collins wrote:
For one thing, I think it might be interesting to explore whether real
objects as keys is actually as difficult as some people are assuming.
I can naively imagine a few ways it could be implemented that seem in
my mind to have minimal impact on any arra
On 17/12/2014 16:58, Stanislav Malyshev wrote:
Hi!
I wonder why you opened voting on this, before resolving the "Open
Issues":
Open Issues
Should SplFixedArray support object indexes?
Should SplObjectStorage support calling __hash for an object if it exists?
These issues are not pa
On 17/12/2014 17:03, Stanislav Malyshev wrote:
Hi!
As I said in the original discussion: this RFC is actually about having
an implicit call to __hash() whenever an object is used as an array key.
You can achieve exactly the same in userland with an explicit call.
It's like nobody have ever see
Hi!
> Just because you say it doesn't affect it doesn't mean it doesn't. I
> think it would be quite silly to support storing hashes and/or storing
> objects and to me that blocks the latter since you are proposing the
> former.
I don't know why you think it's "quite silly" to have both scalar an
On 16 December 2014 at 08:34, Stanislav Malyshev wrote:
> Hi!
>
> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey
>
> I know this is a holiday season but it was extensively discussed and I
> think most people already formed their opinions. I've put the votin
>> and likely prevents us
>> from adding support for objects as keys in the future should we want
>
> No it does not. It was already explained several times. If it is ever
> introduced, it can be used for objects that do not explicitly request
> functionality in this RFC by enabling __hash() with n
Hi!
> This RFC proposes that we store the hash of an object instead of the
> actual object. That's simply not useful to me
Fair enough, but this is not only about what is useful personally to you.
> and likely prevents us
> from adding support for objects as keys in the future should we want
N
This RFC proposes that we store the hash of an object instead of the
actual object. That's simply not useful to me and likely prevents us
from adding support for objects as keys in the future should we want
it.
In addition, it adds yet another behavior to arrays which do so many
things already. I
Hi!
> As I said in the original discussion: this RFC is actually about having
> an implicit call to __hash() whenever an object is used as an array key.
> You can achieve exactly the same in userland with an explicit call.
It's like nobody have ever seen __toString before... Of course you can
do
Hi!
> I wonder why you opened voting on this, before resolving the "Open
> Issues":
>
> Open Issues
>
> Should SplFixedArray support object indexes?
> Should SplObjectStorage support calling __hash for an object if it exists?
These issues are not part of the RFC's target, they are poss
Stanislav Malyshev wrote:
>> Yes, but it is already possible to call an object's method in array key
>> context, so in combination with an appropriate interface the same can be
>> accomplished.
>
> No, it's not possible. It is possible to call object method in an
> expression, and then use the re
guilhermebla...@gmail.com wrote on 17/12/2014 12:43:
Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interf
Rowan Collins wrote:
> Stanislav Malyshev wrote on 17/12/2014 02:14:
>> No, it's not possible. It is possible to call object method in an
>> expression, and then use the result of the expression as an array key.
>> But to do that you'd have to check that you're dealing with the object
>> and the c
On Wed Dec 17 2014 at 1:44:13 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Hi,
>
> Answering the question of Christopher Becker. It is not possible to
> traverse and get your desired elements.
> How would you achieve a foreach by key (returning object) without having to
> sto
guilhermebla...@gmail.com wrote:
> Answering the question of Christopher Becker. It is not possible to
> traverse and get your desired elements.
> How would you achieve a foreach by key (returning object) without having to
> store a separate list and track by hash or through an interface?
AIUI, t
Hi,
Answering the question of Christopher Becker. It is not possible to
traverse and get your desired elements.
How would you achieve a foreach by key (returning object) without having to
store a separate list and track by hash or through an interface?
Cheers,
On Wed, Dec 17, 2014 at 10:04 AM, D
On Tue, 16 Dec 2014, Stanislav Malyshev wrote:
> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey
I wonder why you opened voting on this, before resolving the "Open
Issues":
Open Issues
Should SplFixedArray support object indexes?
Should SplObject
Stanislav Malyshev wrote on 17/12/2014 02:14:
No, it's not possible. It is possible to call object method in an
expression, and then use the result of the expression as an array key.
But to do that you'd have to check that you're dealing with the object
and the call the special method.
I think
Hi!
> Yes, but it is already possible to call an object's method in array key
> context, so in combination with an appropriate interface the same can be
> accomplished.
No, it's not possible. It is possible to call object method in an
expression, and then use the result of the expression as an ar
Hi!
>> On 17 Dec 2014, at 01:32, Stanislav Malyshev
>> wrote:
>>
>> Hi!
>>
>>> AIUI, this RFC is meant to introduce some sugar only. Wouldn't
>>> it be
>>
>> I'm not sure what you mean by "some sugar only". It introduces the
>> capability of using objects in array key context, which was not
Stanislav Malyshev wrote:
>> AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
>
> I'm not sure what you mean by "some sugar only". It introduces the
> capability of using objects in array key context, which was not
> available until now.
Yes, but it is already possible to ca
Hi Stas,
> On 17 Dec 2014, at 01:32, Stanislav Malyshev wrote:
>
> Hi!
>
>> AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
>
> I'm not sure what you mean by "some sugar only". It introduces the
> capability of using objects in array key context, which was not
> available
Hi!
> AIUI, this RFC is meant to introduce some sugar only. Wouldn't it be
I'm not sure what you mean by "some sugar only". It introduces the
capability of using objects in array key context, which was not
available until now.
> possible to have object hashes without __hash(), by introducing a
guilhermebla...@gmail.com wrote:
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
> wrote:
>
>> Are you sure you haven't misinterpreted the RFC?
>
> I did not. You may think I mentioned IdentityMap as entity map, but I'm
> talking about entityPersister mapping or resultPointers consumptions tha
> On Tue, Dec 16, 2014 at 9:39 AM, Matteo Beccati
wrote:Hi Guilherme,
>
>> On 16/12/2014 12:34, Guilherme Blanco wrote:
>> Hi,
>> All I can say is that the lack of this feature is one of the main
reasons why Doctrine doesn't fully work with composite keys.
>> With this enhancement it would now bec
On 16 December 2014 18:50:06 GMT, Stanislav Malyshev
wrote:
>Hi!
>
>> Explicit conversion is trivial, just call whatever method you like.
>> Sure, you can't write (int)$obj, but $obj->toInt() is just as
>> expressive.
>
>Exactly the same applies to __toString and whole ArrayAccess, yet we
>still
Hi!
> Explicit conversion is trivial, just call whatever method you like.
> Sure, you can't write (int)$obj, but $obj->toInt() is just as
> expressive.
Exactly the same applies to __toString and whole ArrayAccess, yet we
still have them. Avoiding boilerplate code helps. Especially if
boilterplate
On 16 December 2014 18:14:27 GMT, Stanislav Malyshev
wrote:
>Hi!
>
>> I was previously in favour of this, but it’d prevent actual indexing
>
>No, of course it won't - if we ever introduce indexing objects (which
>probably will require rewrite of the HashTable, any takers?) it would
>be
>very eas
Hi!
> I was previously in favour of this, but it’d prevent actual indexing
No, of course it won't - if we ever introduce indexing objects (which
probably will require rewrite of the HashTable, any takers?) it would be
very easy to index any object that does not implement __hash without any
BC pr
Hi,
Le 16 déc. 2014 13:45, "Rowan Collins" a écrit :
>
> Patrick Schaaf wrote on 16/12/2014 11:46:
>
>> Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
>>>
>>> On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
by objects i
Patrick Schaaf wrote on 16/12/2014 11:46:
Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
On 16/12/2014 11:52, Andrea Faulds wrote:
I was previously in favour of this, but it’d prevent actual indexing
by objects in future, and I can’t think of any use cases which aren’t
better solved by explicit
Am 16.12.2014 12:36 schrieb "Matteo Beccati" :
>
> On 16/12/2014 11:52, Andrea Faulds wrote:
>>
>> I was previously in favour of this, but it’d prevent actual indexing
>> by objects in future, and I can’t think of any use cases which aren’t
>> better solved by explicitly converting to a string/inte
Hi Guilherme,
On 16/12/2014 12:34, Guilherme Blanco wrote:
Hi,
All I can say is that the lack of this feature is one of the main reasons why
Doctrine doesn't fully work with composite keys.
With this enhancement it would now become possible to implement a proper
IdentityMap.
Are you sure yo
On 16/12/2014 11:52, Andrea Faulds wrote:
This is the main problem with the RFC: magic, implicit, one-way data
loss (object to integer/string).
I was previously in favour of this, but it’d prevent actual indexing
by objects in future, and I can’t think of any use cases which aren’t
better solved
Hi,
All I can say is that the lack of this feature is one of the main reasons why
Doctrine doesn't fully work with composite keys.
With this enhancement it would now become possible to implement a proper
IdentityMap.
[]s,
On Dec 16, 2014, at 9:05 AM, Andrea Faulds wrote:
>>
>> On 16 Dec 201
>
> On 16 Dec 2014, at 10:52, Andrea Faulds wrote:
>
> Exactly. If I were to do this:
>
>class Foo {
>public $foo;
>function __construct($foo) {
>$this->foo = $foo;
>}
>function __toKey() {
>return $this->foo;
>}
>}
>
Hi Markus,
> On 16 Dec 2014, at 10:31, Markus Fischer wrote:
>
> On 16.12.14 09:34, Stanislav Malyshev wrote:
>> I'd like to initiate a vote on "objects as keys" RFC:
>> https://wiki.php.net/rfc/objkey
>
> Am I right this only covers the transformation into the array. Once it's
> in it's essent
On 16.12.14 09:34, Stanislav Malyshev wrote:
> I'd like to initiate a vote on "objects as keys" RFC:
> https://wiki.php.net/rfc/objkey
Am I right this only covers the transformation into the array. Once it's
in it's essential a array compatible key entity (string/integer) so when
you var_dump($arr
44 matches
Mail list logo
