On Wed, Sep 23, 2015 at 5:05 PM, François Laupretre <franc...@php.net> wrote:
> Le 23/09/2015 12:18, Rowan Collins a écrit :
>>
>>
>> Clearly, people misunderstand what isset() does, but I think an exists()
>> function which mimics it with a slight difference will only add to that
>> confusion - people will say "oh, if only I had PHP 7.1" rather than
>> looking for array_key_exists, for instance.
>
>
> Yes, isset() name is misleading and exists() implements the behavior most
> people actually expect from isset(). If a side effect is to motivate people
> to adopt PHP 7, why not ?
What is going to motivate people to adopt PHP 7 is its performance
(and at some point the EOL of 5.x), not whether or not it has an
exists() function ;-)
> If they start replacing calls to
> isset()/array_key_exists() with exists(), that's their choice and it can
> only improve overall readability.
The thing is, it won't really improve overall readability, because the
name exists() is still too vague. It may be obvious to the person who
wrote the code (at least for the first two weeks), then you're really
back into the same vagueness that isset() provides.
I'm still in favor of having a variable_exists('varname') function though.
> My main concern is people using
> isset($foo['bar']) and 'naively' assuming it always returns true when the
> array element exists, because wrong assumptions are always potentially
> problematic. The rest is just a question of completeness and consistency().
> IMO, providing an exists() construct is easy to understand and to remember,
> quite consistent as the scope is the same as isset(), and the drawbacks are
> minimal (including BC break).
>
> Regarding the confusion it may bring, the documentation can be very clear,
> stating that the right tool to check for the existence of an array element
> in pre-7.1 versions is array_key_exists(), not isset().
>
>> So the purpose of hasitem() was not to be a variant of isset(), but to
>> be a well-defined function which served a specific need that people
>> have. If there are other needs that people have, there can be other
>> functions to serve them.
>
>
> 1) hasitem cannot be implemented as a function. It needs to be defined in
> the lexer/parser the same way as exists(), or do you mean it would receive a
> string ? Anyway, if you want to allow 'hasitem($foo['bar'])', it cannot be a
> function like property_exists()/functions_exists().
> 2) it defines 2 names instead of 1,
> 3) the 'hasitem' name is not extremely intuitive,
> 4) it is more complex to implement and I'm not sure I can do it :)
> 5) I don't see the reason to make it artificially more complex and harder to
> remember.
Why would you want to add hasitem()? Writing code that treats arrays,
objects and variables as one thing is a bad practice (unless you
really know what you're doing etc.), and we definitely shouldn't
encourage people by giving them more perfumed band-aid to make smelly
code stink less.
>> Looking at some of your edge-cases:
>>
>>> - array_key_exists() does not handle objects implementing ArrayAccess,
>>
>>
>> Sounds like something which could be fixed in array_key_exists, or
>> easily added to hasitem() without all the other baggage.
>
>
> Possible, yes.
And the right thing to do. Or would you want to have to add special
cases for code depending on whether something was an object and
imlemented ArrayAccess? (There are a lot of cases where ArrayAccess
support is wanting, but that's a different issue.)
> Variable variables provide dynamic names :
>
> $var='var_to_check_'.$i;
> if (exists($$var)) echo "$i: $$var";
>
> IMO, that's not much harder than using variable_exists(<string>).
It is certainly a lot less readable.
- Stig
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
