François Laupretre wrote on 23/09/2015 16:05:
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().
I disagree. I won't go into details, because I will be repeating things
I have said over and over again on this thread.
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.
isset($foo['bar']) is exactly the use case for which I am proposing
hasitem($foo['bar']).
My main concern is that people will use exists($foo) - note no array
access - and rely on a variable being "missing" from a local scope, then
not notice that this doesn't work when you refactor that variable as the
parameter of a new function. Dynamic variable definitions are not
something which most code will benefit from.
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 ?
Yes, I was using the word "function" rather loosely, sorry.
2) it defines 2 names instead of 1,
2 names, for 2 different use cases. I consider this a plus point.
3) the 'hasitem' name is not extremely intuitive,
Indeed, naming is notoriously difficult; feel free to suggest a better one.
4) it is more complex to implement and I'm not sure I can do it :)
I haven't looked in detail at the code, but presumably isset()/exists()
has to detect that you've provided an array access in order to recurse
into it; can hasitem() not just raise an error if it doesn't go into
this recursive path?
5) I don't see the reason to make it artificially more complex and
harder to remember.
More complex internally maybe, but from the user's point of view? You
are proposing an exists() function which does different things in
different contexts, as does isset() (which I suspect is why people
misunderstand it in the first place). I am proposing a function which
does one thing, and one thing only.
- property_exists() does not handle 'magic' properties (those
controlled by magic methods),
exists() cannot meaningfully handle these either, without an additional
magic method; or, it will call __isset(), and return the same value as
isset(), which seems a bit pointless.
Yes, in this case, exists() calls __isset(), and returns the same
value as isset(). It may seem pointless but, unlike static properties,
the logic to consider virtual properties as 'set' or 'unset' is free
and under the responsibility of the developer. He can decide that a
'null' property is 'set' or not. We just relay the information.
My point was that since exists() will have fairly meaningless behaviour
in this case anyway, not handling it in hasitem() isn't a big deal. Just
document that it behaves the same way as property_exists(), not the same
way as isset(), and we're all OK.
As a bonus, if an extra magic method is ever added, property_exists()
and hasitem() can both call it, whereas if exists() is based on a copy
of isset(), it will be hard to change that behaviour later.
- isset() handles string offsets.
What useful functionality could exists() have here?
Probably none but isset() supports it and I want the same scope...
This seems rather a circular argument: you want the same scope to avoid
inconsistencies, but the inconsistencies only matter because you want
the same scope?
I don't see the advantage of having additional edge-cases where isset()
and exists() are guaranteed to return the same value. If you want the
behaviour of isset() on such cases, then you'll still be able to use
isset().
If you're
checking for a variable's existence, you've presumably dynamically
created that variable, so you're quite likely to want the argument to
variable_exists() to also be dynamic. Again, variable_exists() would be
a function which had a well-defined scope, and obvious how to use it.
??
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>).
Not much harder, no, but a bit harder, and for no real gain.
Why require people to put the name into a variable, and use a less
readable syntax? Why not make the function consistent with other
existence checks such as class_exists?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
