Hi!
IMHO defining the value used for the array key should be provided by the
user, like Lester Caine said. Using a state or location based hash behaves
very unexpectedly and I doubt it would be used very much because of that.
Regarding __toString vs. __hash. It depends on what __toString really
On 26/09/14 08:36, Stas Malyshev wrote:
>> I think it makes more sense than a new method on all objects. You could
> Nobody talks about "new method on all objects" (it's also not really
> possible in PHP). We're talking about new magic method, which allows the
> developer to control how class is tr
Hi!
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is
> here: https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could
Nobody talks about "new method on all objects" (it's also not really
possible in PHP). W
Hi,
On Thu, 2014-09-25 at 12:22 +0200, Florian Margaine wrote:
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could use
> it for any kind of value
Le 25 sept. 2014 12:54, "Pierre Joye" a écrit :
>
> On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine
wrote:
> > Hi,
> >
> > Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> > https://github.com/krakjoe/php-src/compare/addressof
> >
> > I think it makes more sense than a
On Thu, Sep 25, 2014 at 12:22 PM, Florian Margaine wrote:
> Hi,
>
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
> https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could use
> it for any kind of val
Hi,
Joe Watkins wrote (for fun) a new operator, `addressof`. Code is here:
https://github.com/krakjoe/php-src/compare/addressof
I think it makes more sense than a new method on all objects. You could use
it for any kind of value: scalar, resource, object. Building an array of
sockets, for example
On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds wrote:
>
> On 24 Sep 2014, at 20:39, Stas Malyshev wrote:
>
>>> I also wonder why we still need them. Doing what has been done with gmp
>>> for all resources would be a good move for 7.
>>
>> In general, I think we do not - IIRC everything resources
On 25 September 2014 09:21, Lester Caine wrote:
>
> 'This function returns a unique identifier for the object.'
> There is a mistaken view in some usage that that will be DIFFERENT for
> different versions of the same object.
Not sure who has that view. It's quite clearly documented, for the
life
On 25/09/14 08:44, Leigh wrote:
> On 25 September 2014 08:40, Lester Caine wrote:
>> >
>> > Why would we need to build a hash of this object? It would provide
>> > nothing of use since we have a clean object key. Some people seem to
>> > think a hash will provide an indication that an object has c
On 25 September 2014 08:40, Lester Caine wrote:
>
> Why would we need to build a hash of this object? It would provide
> nothing of use since we have a clean object key. Some people seem to
> think a hash will provide an indication that an object has changed, but
> in reality that is also reliant
On 25/09/14 06:19, Patrick Schaaf wrote:
> Am 24.09.2014 22:01 schrieb "Andrea Faulds" :
>> >
>> > 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 s
Am 24.09.2014 22:01 schrieb "Andrea Faulds" :
>
> 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 s
On 24 Sep 2014, at 21:46, Johannes Schlüter wrote:
> 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.
On Wed, 2014-09-24 at 20:45 +0100, Andrea Faulds wrote:
> On 24 Sep 2014, at 13:24, Johannes Schlüter wrote:
>
> > Taking this sample code:::
> >
> > > class C {
> >function __toString() {
> >return "C";
> >}
> > }
> >
> > $a = [];
> >
> > $c1 = new C();
> > $c2 = new C();
> >
On 24 Sep 2014, at 21:08, Stas Malyshev wrote:
> 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
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:
>
On 24 Sep 2014, at 20:56, Stas Malyshev wrote:
>> There the assumption would be that this leads to an array $a with two
>> elements, where in fact there is only one if __toString() is being
>> called. The only thing "making sense" would be using using the objects
>> identity (i.e. via spl_object
Hi!
> I already figured out how to solve the `is_resource()` issue. Create
> an almost-useless, uninstantiatable class called Resource which any
> new resource-replacing classes inherit from. Then, make
> `is_resource()` check whether something is an instance of that
> class.
This is a nice idea,
Hi!
> There the assumption would be that this leads to an array $a with two
> elements, where in fact there is only one if __toString() is being
> called. The only thing "making sense" would be using using the objects
> identity (i.e. via spl_object_hash()) everything else leads to issues.
This i
On 24 Sep 2014, at 13:24, Johannes Schlüter wrote:
> Taking this sample code:::
>
> class C {
>function __toString() {
>return "C";
>}
> }
>
> $a = [];
>
> $c1 = new C();
> $c2 = new C();
>
> $a[$c1] = 23;
> $a[$c2] = 42;
> ?>
>
> There the assumption would be that this lea
On 24 Sep 2014, at 20:39, Stas Malyshev wrote:
>> I also wonder why we still need them. Doing what has been done with gmp
>> for all resources would be a good move for 7.
>
> In general, I think we do not - IIRC everything resources do objects can
> do better now, and the problems that prevente
Hi!
> I also wonder why we still need them. Doing what has been done with gmp
> for all resources would be a good move for 7.
In general, I think we do not - IIRC everything resources do objects can
do better now, and the problems that prevented one from using objects
instead of resources are lon
Hi,
On Tue, 2014-09-23 at 10:04 +0200, Nicolai Scheer wrote:
> until 5 minutes ago I thought it would be perfectly legal to use an object
> as an array key, given that its __toString() method is in place.
Taking this sample code:::
There the assumption would be that this leads to an array $a w
On Sep 24, 2014 10:19 AM, "Michael Wallner" wrote:
>
> On 24/09/14 08:30, Stas Malyshev wrote:
> > Hi!
> >
> >> Well, then let's remove this restriction from resources, too.
> >
> > Not sure what use would it be for resources - resource IDs are not
> > controlled by user code and for all intents a
On 24/09/14 08:30, Stas Malyshev wrote:
> Hi!
>
>> Well, then let's remove this restriction from resources, too.
>
> Not sure what use would it be for resources - resource IDs are not
> controlled by user code and for all intents and purposes are opaque
> numbers, which also do not have to be uni
Hi!
> Well, then let's remove this restriction from resources, too.
Not sure what use would it be for resources - resource IDs are not
controlled by user code and for all intents and purposes are opaque
numbers, which also do not have to be unique over the life of the
script. What use would it be
On 24/09/14 02:08, Stas Malyshev wrote:
> Hi!
>
>> I do believe that the UString class would benefit from such a change.
>>
>> Why would it be confusing to implement this?
>
> For some objects, it may lead to rather strange results - i.e.,
> Exception has __toString() but probably not very useful
Hi!
> I do believe that the UString class would benefit from such a change.
>
> Why would it be confusing to implement this?
For some objects, it may lead to rather strange results - i.e.,
Exception has __toString() but probably not very useful one for use as
an array key. So may some other __to
Hi,
I do believe that the UString class would benefit from such a change.
Why would it be confusing to implement this?
Regards,
*Florian Margaine*
Le 23 sept. 2014 12:42, "Michael Wallner" a écrit :
> On 2014-09-23 11:45, Leigh wrote:
> > On 23 September 2014 10:35, Michael Wallner wrote:
>
On 2014-09-23 11:45, Leigh wrote:
> On 23 September 2014 10:35, Michael Wallner wrote:
>> On 2014-09-23 11:15, Leigh wrote:
>>> 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
On 23 September 2014 10:35, Michael Wallner wrote:
> On 2014-09-23 11:15, Leigh wrote:
>> 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 co
On 2014-09-23 11:15, Leigh wrote:
> On 23 September 2014 09:51, Michael Wallner wrote:
>>
>> 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
On Tue, Sep 23, 2014 at 12:29 PM, Andrea Faulds wrote:
>
>> On 23 Sep 2014, at 10:15, Leigh wrote:
>>
>>> On 23 September 2014 09:51, Michael Wallner wrote:
>>>
>>> Yes, it was removed intentionally (quite a long time ago), like using
>>> resources as array keys, to avoid hard-to-trace bugs for
> On 23 Sep 2014, at 10:15, Leigh wrote:
>
>> On 23 September 2014 09:51, Michael Wallner wrote:
>>
>> 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.
>
On 23 September 2014 09:51, Michael Wallner wrote:
>
> 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
On 2014-09-23 10:04, Nicolai Scheer wrote:
> Hi all,
>
> until 5 minutes ago I thought it would be perfectly legal to use an object
> as an array key, given that its __toString() method is in place.
>
> Seems as if I was wrong.
> I know that array keys are not what is considered "string context"
Hi all,
until 5 minutes ago I thought it would be perfectly legal to use an object
as an array key, given that its __toString() method is in place.
Seems as if I was wrong.
I know that array keys are not what is considered "string context"
internally, at least not directly.
Would it harm in any
38 matches
Mail list logo
