Hi Rowan,
Le 22/09/2015 12:49, Rowan Collins a écrit :
I take it you didn't like my suggestion of separate functions for
hasitem() and variable_exists() then?
I think there are two very different use cases here, and combining them
will just add to the confusion which isset() already seems to cause.
A variable_exists() which took a string (in keeping with class_exists(),
function_exists(), etc) would also be more powerful, since you could
write things like variable_exists('foo_' . $i)
My primary idea was, as you suggested, to provide a variable_exists()
function, restricted to variables, an hasitem() construct, reserved to
array elements, similar to array_key_exists(), and consider that
property_exists() is sufficient for class properties.
Unfortunately, when I started to compare behaviors between isset(),
array_key_exists(), and property_exists(), I discovered that isset() has
a much marger scope that array_key_exists()/property_exists(). Among
other inconsistencies :
- array_key_exists() does not handle objects implementing ArrayAccess,
- property_exists() does not handle 'magic' properties (those controlled
by magic methods),
- isset() handles string offsets.
So, I thought this was going further and further away from the original
idea, which was asking for 'an equivalence of isset() which would
consider every value, *including* null, as set, because that's what a
lot of devs intuitively assume when using isset()'. That's why I
reverted to a unique exists() construct, whose scope is exactly the same
as isset().
IMHO, that's the best solution, but anybody is free to provide another
patch/implementation.
Note: A variable_exists() function accepting a string wouldn't be more
powerful, as exists() provides the same feature when using a '$$'
variable variable.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
