On Tue, Sep 1, 2015 at 5:29 AM, Craig Francis <cr...@craigfrancis.co.uk> wrote: > Hi Rowan, Ryan, James, Bishop, Stas, Lester, > > I've been giving this some thought over the weekend, and I agree with what > you are all saying, but I think there is an element of confusion in the PHP > programming community that needs to be addressed (somehow). > > Yes, we probably should not be giving special meaning to NULL, as James > mentions (although I probably still will). > > And to be fair, I still can't think of an example where isset() can be used > on a standard variable. All my examples are really array based, and better > addressed with array_key_exists() - where Rowan does a great job of > explaining the different examples on stackoverflow: > > http://stackoverflow.com/a/18646568/2908724 > > Trying to get to route of the confusion though, I think it might be down to > how the code can be read. So if we take: > > <?php > $a = 1; > $b = NULL; > var_dump($a); > var_dump($b); > var_dump($c); > var_dump(isset($a)); > var_dump(isset($b)); > var_dump(isset($c)); > ?> > > Or using an array instead: > > <?php > $v['a'] = 1; > $v['b'] = NULL; > var_dump($v['a']); > var_dump($v['b']); > var_dump($v['c']); > var_dump(isset($v['a'])); > var_dump(isset($v['b'])); > var_dump(isset($v['c'])); > ?> > > In both cases (and ignoring the undefined variable error), we get: > > int(1) > NULL > NULL > > bool(true) > bool(false) > bool(false) > > But if we ignore the manual for a minute: > > http://php.net/isset > > I think a good comparison to what that code reads as, vs what PHP does, can > be summarised as: > > Read as: The variable is set (exists). > > Executed as: The variables *value* is set. > > Where NULL is not considered a set value. > > So when we have: > > if (isset($v['a'])) { > } > > It's not saying that the key 'a' is set (exists) on the array $v. > > Instead its saying that the key 'a' has a set value (not NULL) on the array > $v. > > Where this is made more of a common problem because there are many array_* > functions, and they rarely come to mind when your not thinking of an array > like operation. > > This situation might be improved by re-wording the manual a bit. > > Having headings like "This also work[s] for elements in arrays", makes it > sound all inclusive and *the* function to use. > > Whereas I'm starting to get the feeling that isset() is actually a function > that probably should be avoided (I'll skip this tangent for now). > > Personally I still like the idea of an exists(), because I feel that is how > many programmers treat and use the isset() function - simply because they do > use NULL as a valid value, and either haven't read the manual, or forget the > exception that is mentioned on line 1 (something I've done a couple of times). > > Although I realise it will take many years before anyone can start using it. > > Craig > > > > > > > > > On 26 Aug 2015, at 19:44, Rowan Collins <rowan.coll...@gmail.com> wrote: > >> Craig Francis wrote on 26/08/2015 18:07: >>> I provide examples to help explain that I (and I suspect most developers) >>> default to using isset which works on either. >>> >>> Just because there is a function, which does not exactly roll off the >>> tongue (plus the fun of the needle/haystack ordering issue), does not mean >>> it gets used (even if it is the correct thing to use). >> >> >> That's all very well, but what is the Internals community supposed to do >> about it? Does the documentation need to be improved to point out that there >> is a better function to use for this case? >> >>> I say "or key" because developers use the isset function on both $var and >>> $var['key']... yes, I know they are different, but when you are coding in >>> PHP an isset check is an isset check (well it isn't, because the variable >>> may technically exist). >>> >>> If this is a problem, maybe PHP should raise a notice when isset is used on >>> arrays? >> >> >> It's only a problem in the same way that using file_exists() is a problem >> when you actually wanted the functionality of is_readable() - both functions >> exist, and it's not the language's responsibility to guess which you meant. >> >> >> >>>>> where NULL may be a perfectly valid value. >>>> It's not that NULL isn't a valid value; it's that "doesn't exist" isn't a >>>> meaningful state for a variable. It's like checking if the current line >>>> number is greater than 100, it shouldn't mean anything to the compiled >>>> program. See the SO answer I linked earlier for more thought experiments >>>> along these lines. >>> >>> I think you have been spending too much time in C. >>> >>> Most of the PHP code bases I've worked on set variables to NULL at some >>> point (and they are not calling unset, because that isn't the intention). >> >> >> Perhaps my double negative made it unclear, so I will restate: there is >> nothing wrong with setting a variable to NULL. There is also nothing wrong >> with calling unset() on a plain variable, e.g. to make it obvious to readers >> of the code that this variable should not be used below this point. >> >> There IS something wrong with any code which needs to distinguish which of >> those two things happened, at run-time, because such code would be >> incredibly fragile and hard to follow. >> >> You could, if you wanted, emulate a boolean variable by using $foo=null for >> true, and unset($foo) for false, but why not simply have a boolean variable? >> >> [Incidentally, I know barely any C, but program PHP for a living.] >> >> Regards, >> -- >> Rowan Collins >> [IMSoP] >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
The pieces are already in place, if this is a desired feature we just have to bring them together. * array_key_exists() * get_defined_vars() I do agree that it would be years before anyone got to use it (either 7.1.0 or 8.0.0). I don't see that as a bad thing, this was low-hanging fruit. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
