On 2 Sep 2015, at 13:31, Rowan Collins <rowan.coll...@gmail.com> wrote:
> In summary, I don't think any language change is needed here, but > documentation needs to be improved. I will have a go at drafting a new intro > for the isset() page when/if I get time. Maybe... personally I don't see why anyone would be performing operations such as: exists($foo['bar'] + 1) In the same way that `isset($a + 1)` results in a parse error. But then again, I don't think it's a quirk that "you don't get a warning when passing a completely undefined variable to isset()", as I don't see isset() as a normal function. If you do treat is as a normal function, you might as well be using is_null() or "=== NULL". For example, I think its quite common for MVC style frameworks to check if a variable exists (with isset) in a View (e.g. checking if a paginator exists after printing the table of results). With the `exists($foo['bar']['baz'])` example, I just see that as a simple: if $foo exists, and contains the key 'bar', and contains the key 'baz' (no need to check values). Like isset() I see exists() as a special function that isn't passing a variable in, but PHP doing some analysis of the thing in the brackets. Craig On 2 Sep 2015, at 13:31, Rowan Collins <rowan.coll...@gmail.com> wrote: > Craig Francis wrote on 02/09/2015 10:06: >> On 1 Sep 2015, at 19:17, Rowan Collins <rowan.coll...@gmail.com> wrote: >> >>> I'm still not sure how exists() would be anything other than an alias for >>> array_key_exists(). >> >> I think that is the case as well (ish). >> >> But considering that isset() seems to be the function that is used most of >> the time, I want to consider why that is the case. >> >> Before last week, if someone asked me to write some code to see if a >> variable (or key) exists, > > Again, you insist on drawing a false equivalence to the different concepts of > variable and array key. This makes the following sentence really easy to > dismiss: > > >> I would have simply used isset() without thinking (this being a problem if >> the variable was set to NULL). > > No, it wouldn't be a problem if a VARIABLE was set to null, because there is > no practical difference between an unset variable and one set to null, so you > never need to ask which you have. > > It *would* be a problem if you were testing for the existence of an array > key. There should probably be a prominent link to array_key_exists() and > property_exists() on the isset() manual page > > >> The second one does also represent the variable in a different way (grep for >> "$_GET['q']", where it only appears 3 times in that code). > > This is a more reasonable point, and I was pondering whether it would be > possible to allow a more natural syntax. > > It would probably require a lot of "magic" in the engine, though, because it > would have to parse exists($foo['bar']['baz']) in some special way to know > that it needed to first find the value of $foo['bar'], and then do an > existence check for key 'baz', rather than just treating the whole thing as > an expression to resolve before exists() was called. Evaluating things like > exists(foo()[ bar() ]) correctly might get messy, as would giving a > meaningful result or error if you wrote exists($foo['bar'] + 1). > > >> And the second one does not really check for the existence of $_GET, which >> in this case is probably ok. > > I'm not really sure what you mean by this. > > > In summary, I don't think any language change is needed here, but > documentation needs to be improved. I will have a go at drafting a new intro > for the isset() page when/if I get time. > > Regards, > -- > Rowan Collins > [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
