Re: [PHP-DEV] Invokation on __toString() for object used as array key
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). We're talking about new magic method, which allows the developer to control how class is treated when used as hash key. Note it is not always the same as object's identity - you may want two GMP numbers with value of 1 actually refer to the same key in the hash, just like two numbers 1 do. use it for any kind of value: scalar, resource, object. Building an array of sockets, for example, would be very easy with such an operator. Building an array of sockets is easy right now. Same with array of any variables. What is not easy is using socket as an index, but why exactly would you want to do that? It would also give better tools to deal with situations such as: $test = 1; $test2 = $test; Why it is the situation that must be dealt with? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 treated when used as hash key. Note it is not always the same as object's identity - you may want two GMP numbers with value of 1 actually refer to the same key in the hash, just like two numbers 1 do. This is actually the one I'm trying to work around ... The key is well defined as it's the BIGINT value on the database but I am unsure exactly what is going on with all the discussions on 64 bit processing if the same integer key will be available on 32bit builds. Which is where what other 'hash/simple assign' methods return is something that would be nice to know. For different builds to produce completely different results is a problem, but since in my book __toString() simply needs to be manually populated anyway, populating it with something suitable is not a problem. I don't see how anything 'memory location' based makes a sensible default for that? Automatically populating with something content based is simply not practical? So adding a __toHash does not provide any gain since it has the same problem? The main advantage of PHP is that it IS loosely defined so we can bend it to our own way of working, so some 'defaults' would be better as simply better documented explanations on why manual assistance is more appropriate. __toString() is one of those cases. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 is for. Now that there is a dedicated __debugInfo method, should __toString enable an object to be used as a string without exception? In this case there is no need for a separate method. Having a separate method might actually be confusing. When a string is expected __toString is called, except when ... If that is not the purpose of __toString() than a separate method makes more sense. I agree with johannes that __toString is often used for debugging. I do that quite a bit. However since this would be new functionality there is no BC break and users can be informed before using it. I tried to summarize the four approaches, just to make sure I understood them correctly. Using __toString() toString not set will lead all instances to use the same (empty) array key thus overwriting each other. toString is often used to generate a string represantation of the class. Imagine an emailClass, where toString return the email body. This would lead to huge unwieldy array keys, though technically fine. toString then has three jobs: 1. Output for debug (even though there is a new function for that, it is still often used for that) 2. Textual representation, like an email-body or the content of a stream. 3. array key Currently the following error is thrown, when no __toString function is defined Fatal error: Object of class O could not be converted to string. If it read Fatal error: Object of class O could not be converted to string. Expected method __toString(). It would point users in the right direction. new magic method __hash -- This relieves the ambiguity of __toString. It also enables the user to define a key that is sensible for his use case, for example a user id or database id. Currently it issues a warning Warning: Illegal offset type. If a new magicc method is implemented than it should read Warning: Illegal offset type object. Object has no method __hash() state based Hash --- A state based hash can be made somewhat readable, but changing state changes the hash. $a = new MyClass(); $a-foo = 'bar'; $d = array( $a = 'It Works'); $a-foo = 'buzz'; echo $d[$a]; // Notice: Undefined index On the other hand this would work (Imagine storing something in the session or database and trying to access it from a different instance or from a later request) $a = new MyClass(); $a-foo = 'bar'; $d = array( $a = 'It Works'); $b = serialize($a); $a = unserialie($b); echo $d[$a]; // It Works! internal pointer based Hash Changing the state of the object would not change its hash so this works: $a = new MyClass(); $a-foo = 'bar'; $d = array( $a = 'It Works'); $a-foo = 'buzz'; echo $d[$a]; // It works But this would not work $a = new MyClass(); $a-foo = 'bar'; $d = array( $a = 'It Works); $b = serialize($a); $a = unserialie($b); echo $d[$a]; // Notice: Undefined index -- john
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25/09/14 06:19, Patrick Schaaf wrote: Am 24.09.2014 22:01 schrieb Andrea Faulds a...@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. The problem here is that while OOP has been brought into PHP it's rules have never been fully documented? Using a practical example, if I have an object for say an individual on a family tree data set, there are several elements that can be used as a key or an identifier that the content has changed. The unique ID will need to be used as a key, while a more display friendly 'toString' content including the full name may be more appropriate. We end up with additional functions to create more formalised control of the display functions. 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 what information is imported when the object is loaded. I don't see anything here that can work 'automatically' and be practical? As with much of PHP, this is simply a matter of coding style, and providing a consistent style of object creation THAT IS IDEAL FOR YOUR APPLICATION. Much of the current automatic processes are a compromise and we may get better results by overriding those. Building in more guesses does not seem good practice, but we still do not have particularly good practical demonstrations on how to use much of these advanced features. Currently there is no requirement that __toString will produce a unique ID at all anyway? Adding a new function with that requirement just seems overkill. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25 September 2014 08:40, Lester Caine les...@lsces.co.uk 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 what information is imported when the object is loaded. Nothing to do with when the object is changed. http://php.net/spl_object_hash -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25/09/14 08:44, Leigh wrote: On 25 September 2014 08:40, Lester Caine les...@lsces.co.uk 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 what information is imported when the object is loaded. Nothing to do with when the object is changed. http://php.net/spl_object_hash '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. So what *IS* returned by spl_object_hash? The UCN from 7 years ago flags that the identifier is only based on the internal pointers to the object in memory and that the result is not user friendly, but without digging into the code, the problems such as the fact that re-use of the buffer space by a later object cached in the same buffer may be the same as ID? It is not immediately obvious that using a buffer to load data to build a more compact array would have the SAME spl_object_hash for every entry ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 25 September 2014 09:21, Lester Caine les...@lsces.co.uk 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 lifetime of an object, it will always have the same hash. So what *IS* returned by spl_object_hash? The UCN from 7 years ago flags that the identifier is only based on the internal pointers to the object in memory and that the result is not user friendly, but without digging into the code, the problems such as the fact that re-use of the buffer space by a later object cached in the same buffer may be the same as ID? Yes it is created using various internal pointers, and is about as user-friendly as any other kind of hash. It is possible to create a duplicate hash if you unset an object, force GC collection, and then create a new object which can occupy the same memory location. var_dump(spl_object_hash(new stdClass())); gc_collect_cycles(); var_dump(spl_object_hash(new stdClass())); This is a fairly unrealistic scenario, however Joe Watkins has developed a better hash method that doesn't have this flaw, I don't know if he ever intended to have it applied to core or not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds a...@ajf.me wrote: On 24 Sep 2014, at 20:39, Stas Malyshev smalys...@sugarcrm.com 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 prevented one from using objects instead of resources are long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. 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. Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). Is it really necessary? I could imagine a transition with 5.7 for that, similar to gmp. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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, would be very easy with such an operator. It would also give better tools to deal with situations such as: $test = 1; $test2 = $test; I'm willing to write an RFC if necessary to include it. Thoughts? On Thu, Sep 25, 2014 at 11:50 AM, Pierre Joye pierre@gmail.com wrote: On Wed, Sep 24, 2014 at 9:44 PM, Andrea Faulds a...@ajf.me wrote: On 24 Sep 2014, at 20:39, Stas Malyshev smalys...@sugarcrm.com 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 prevented one from using objects instead of resources are long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. 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. Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). Is it really necessary? I could imagine a transition with 5.7 for that, similar to gmp. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- Regards, *Florian Margaine*
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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: scalar, resource, object. Building an array of sockets, for example, would be very easy with such an operator. For one this leaks quite some implementation details to userland which we shouldn't do aside from debugging features. Secondly this becomes unintuitive with value objects (see my DateTime example in this thread) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 to index by those, especially by implicit convert? I don't think right now we have implicit convert of resources to ints anywhere, like we do have with __toString. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 unique over the life of the script. What use would it be to index by those, especially by implicit convert? I don't think right now we have implicit convert of resources to ints anywhere, like we do have with __toString. There's currently no way to associate any data with a resource, except by its ID. $context[(int) $resource] = ...; IIRC resources *were* implicitely converted to integers up until a specific version, I'll have to look that up in history, though. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Sep 24, 2014 10:19 AM, Michael Wallner m...@php.net 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 and purposes are opaque numbers, which also do not have to be unique over the life of the script. What use would it be to index by those, especially by implicit convert? I don't think right now we have implicit convert of resources to ints anywhere, like we do have with __toString. There's currently no way to associate any data with a resource, except by its ID. $context[(int) $resource] = ...; IIRC resources *were* implicitely converted to integers up until a specific version, I'll have to look that up in history, though. 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.
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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:::
?php
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 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.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 20:39, Stas Malyshev smalys...@sugarcrm.com 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 prevented one from using objects instead of resources are long gone. However, is_resource() checks and lots of third-party extensions using resources may be a bit of a problem for eliminating them. 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. Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 13:24, Johannes Schlüter johan...@schlueters.de wrote:
Taking this sample code:::
?php
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 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.
I’m not sure this is a fair example. Don’t classes usually implement a
`__toString()` that is based on the data they contain? If they don’t, I’m not
sure they’re useful for indexing anyway.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 is a valid concern. For this, Java, for example, has separate methods hashCode() and toString(). Python has __str__, __repr__ and __hash__. Ruby has object.hash. So maybe we should have another magic, something like __hash(), that would produce a value for key? Then objects that implement __hash would be hashable and those that don't won't be, while still having usable __toString. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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, but maybe interface would be even better? Of course, 3rd-party extensions are still a problem, but this should mostly fix it. Of course, gettype() is still going to return “object” not “resource”, but I suspect people are more likely to use is_resource(). yeah, I don't think I've seen many examples of something like checking gettype() of fopen() return. I've definitely seen checking it for is_resource. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 20:56, Stas Malyshev smalys...@sugarcrm.com 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_hash()) everything else leads to issues.
This is a valid concern. For this, Java, for example, has separate
methods hashCode() and toString(). Python has __str__, __repr__ and
__hash__. Ruby has object.hash. So maybe we should have another magic,
something like __hash(), that would produce a value for key? Then
objects that implement __hash would be hashable and those that don't
won't be, while still having usable __toString.
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)
}
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.
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.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 21:08, Stas Malyshev smalys...@sugarcrm.com 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 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.
Actually, yeah, I see your point. I suggest this, then:
public function __toKey() : int | string {}
Psuedo-code, since you can’t have multiple return types. I think it’s a better
name than __hash (fits well with __toString IMO), and this way we can support
integer keys too, where that makes sense.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Wed, 2014-09-24 at 20:45 +0100, Andrea Faulds wrote:
On 24 Sep 2014, at 13:24, Johannes Schlüter johan...@schlueters.de wrote:
Taking this sample code:::
?php
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 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.
I’m not sure this is a fair example. Don’t classes usually implement a
`__toString()` that is based on the data they contain? If they don’t,
I’m not sure they’re useful for indexing anyway.
Usually is a bad term - we have no idea what 99% of our suers do ;)
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.
The interesting question are value objects
?php
$a = new DateTime(2014-09-24);
$b = new DateTime(2014-09-24);
$c = $a;
$d = [];
$d[$a]++;
$d[$b]++;
$d[$c]++;
?
We can define we're using object identity as I did above or we add a
__hash() method, which again is more magic.
Last time this was discussed the magic didn't win and therefore having
objects as keys is forbidden so the user has to decide on
hashing/identifying himself in an explicit way.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 24 Sep 2014, at 21:46, Johannes Schlüter johan...@schlueters.de 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.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
Am 24.09.2014 22:01 schrieb Andrea Faulds a...@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
[PHP-DEV] Invokation on __toString() for object used as array key
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 way to add that feature? Greetings Nico
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 internally, at least not directly. Would it harm in any way to add that feature? 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. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 September 2014 09:51, Michael Wallner m...@php.net 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 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 Sep 2014, at 10:15, Leigh lei...@gmail.com wrote: On 23 September 2014 09:51, Michael Wallner m...@php.net 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 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'd be great if, for the UString class krakjoe is working on, it could implicitly convert. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On Tue, Sep 23, 2014 at 12:29 PM, Andrea Faulds a...@ajf.me wrote:
On 23 Sep 2014, at 10:15, Leigh lei...@gmail.com wrote:
On 23 September 2014 09:51, Michael Wallner m...@php.net 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 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 2014-09-23 11:15, Leigh wrote: On 23 September 2014 09:51, Michael Wallner m...@php.net 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 invoke __toString(). Did I write that? Is there really any harm in adding a IS_OBJECT case to zend_whatever_add_array_element, and checking if it has a __toString? As already mentioned that behavior was intentionally removed. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 23 September 2014 10:35, Michael Wallner m...@php.net 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 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 :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
On 2014-09-23 11:45, Leigh wrote: On 23 September 2014 10:35, Michael Wallner m...@php.net 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 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'm a victim of $array[(int) $resource] myself. I just tried to explain that the behavior is intentional and not an oversight. That doesn't mean that is set in stone for all times. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 m...@php.net a écrit : On 2014-09-23 11:45, Leigh wrote: On 23 September 2014 10:35, Michael Wallner m...@php.net 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 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'm a victim of $array[(int) $resource] myself. I just tried to explain that the behavior is intentional and not an oversight. That doesn't mean that is set in stone for all times. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 __toString methods. But in general, if we streamline the conversion rules and set expectations, I don't see why PHP engine can not check for object's convertor to string and even to int if string one is not there. Yes, that would hide some errors but also will enable some capabilities (like much smoother work with objects that may simulate numbers, akin to GMP). -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invokation on __toString() for object used as array key
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 one for use as an array key. So may some other __toString methods. But in general, if we streamline the conversion rules and set expectations, I don't see why PHP engine can not check for object's convertor to string and even to int if string one is not there. Yes, that would hide some errors but also will enable some capabilities (like much smoother work with objects that may simulate numbers, akin to GMP). Well, then let's remove this restriction from resources, too. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
