Re: PHP 7.1 - Address PHPSadness #28?

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