Re: PHP 7.1 - Address PHPSadness #28?

From: Date: Mon, 07 Sep 2015 13:11:05 +0000
Subject: Re: PHP 7.1 - Address PHPSadness #28?
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-88094@lists.php.net to get a copy of this message
On 2 Sep 2015, at 13:31, Rowan Collins <rowan.collins@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.collins@gmail.com> wrote: > Craig Francis wrote on 02/09/2015 10:06: >> On 1 Sep 2015, at 19:17, Rowan Collins <rowan.collins@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]

« previous php.internals (#88094) next »