FAQ

[PHP-INTERNALS] [RFC] Allow non-variable arguments to empty() and isset()

Nikita Popov
Apr 12, 2012 at 9:42 pm
Hi internals!

As per the comments I created an RFC, proposing to allow arbitrary
expressions to be passed to empty() and isset():

https://wiki.php.net/rfc/empty_isset_exprs

The patch is available as a PR:

https://github.com/php/php-src/pull/54

Nikita

PS: I added isset() too, to address the consistency concerns mentioned on IRC.
reply

Search Discussions

30 responses

  • Galen Wright-Watson at Apr 12, 2012 at 10:43 pm

    On Thu, Apr 12, 2012 at 2:42 PM, Nikita Popov wrote:
    As per the comments I created an RFC, proposing to allow arbitrary
    expressions to be passed to empty() and isset():

    https://wiki.php.net/rfc/empty_isset_exprs

    The patch is available as a PR:

    https://github.com/php/php-src/pull/54

    Nikita

    PS: I added isset() too, to address the consistency concerns mentioned on
    IRC.

    Just to be clear, under the new behavior, calling "empty" or "isset" on
    undefined variables and undefined array indices shouldn't produce a notice
    when E_NOTICE is set, correct? Basically, the change isn't regressive.

    <?php
    error_reporting(E_ALL);
    echo empty($foo) ? "\$foo isn't set\n" : "foo: $foo\n";
    # result: "$foo isn't set", and no "Undefined variable" notice.

    From my reading of the patch this is true, but I want to make sure I'm not
    missing something. If this is so, how about adding appropriate regression
    tests to empty_with_expr.phpt and empty_with_isset.phpt?
  • Nikita Popov at Apr 13, 2012 at 12:12 pm

    On Fri, Apr 13, 2012 at 12:42 AM, Galen Wright-Watson wrote:
    Just to be clear, under the new behavior, calling "empty" or "isset" on
    undefined variables and undefined array indices shouldn't produce a notice
    when E_NOTICE is set, correct? Basically, the change isn't regressive.
    Yup, that's right. So the change is BC-safe :)
    If this is so, how about adding appropriate regression
    tests to empty_with_expr.phpt and empty_with_isset.phpt?
    The normal empty()/isset() behavior (including the suppression of the
    notice) is tested in a few other tests, that's why I didn't add
    additional tests for it there :)

    Nikita
  • Patrick ALLAERT at Apr 30, 2012 at 7:50 am
    Hi,

    2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>:
    PS: I added isset() too, to address the consistency concerns mentioned on IRC.
    I would have voted +1 if it didn't contain the isset() change. None of
    the examples used in the isset_with_expr.phpt test seems logic to me.

    Care to explain the consistency concerns here?

    Patrick
  • Nikita Popov at Apr 30, 2012 at 12:39 pm

    On Mon, Apr 30, 2012 at 9:50 AM, Patrick ALLAERT wrote:
    Hi,

    2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>:
    PS: I added isset() too, to address the consistency concerns mentioned on IRC.
    I would have voted +1 if it didn't contain the isset() change. None of
    the examples used in the isset_with_expr.phpt test seems logic to me.

    Care to explain the consistency concerns here?
    The concerns came from laruence, so maybe he could drop a comment here
    :) Basically, empty() and isset() are very similar in their nature, so
    changing only one of them might seem inconsistent.

    Personally I don't see much use in allowing expressions in isset().
    People being confused by empty(trim($_GET['foo'])) not working is
    quite common, but I've never heard of somebody trying to use isset()
    on a function call. The name already makes clear that it's intended
    for use on variables.

    So, I'm not quite sure what I'm supposed to do about this. Should I
    add two vote options, one for empty() only, one for both?

    Nikita
  • Ferenc Kovacs at May 1, 2012 at 4:43 pm

    On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov wrote:
    On Mon, Apr 30, 2012 at 9:50 AM, Patrick ALLAERT wrote:
    Hi,

    2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>:
    PS: I added isset() too, to address the consistency concerns mentioned
    on IRC.
    I would have voted +1 if it didn't contain the isset() change. None of
    the examples used in the isset_with_expr.phpt test seems logic to me.

    Care to explain the consistency concerns here?
    The concerns came from laruence, so maybe he could drop a comment here
    :) Basically, empty() and isset() are very similar in their nature, so
    changing only one of them might seem inconsistent.

    Personally I don't see much use in allowing expressions in isset().
    People being confused by empty(trim($_GET['foo'])) not working is
    quite common, but I've never heard of somebody trying to use isset()
    on a function call. The name already makes clear that it's intended
    for use on variables.

    albeit I'm not laruence, but I also supported the idea to keep consistency
    across the allowed params of empty and isset.
    here is my reasoning:
    - both isset and empty are language constructs, which many people use
    almost interchangeability, changing one of them in a way that the same
    expression works with one of them, but blows up with a parse error seems
    wrong to me.
    - maybe you think that isset doesn't really make sense with expressions,
    but don't forget that this patch would also allow constants to be used with
    empty/isset, and imo isset(some_constant); would be useful and maybe more
    straightforward for the people new to the language.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Etienne Kneuss at May 1, 2012 at 4:52 pm
    Hi,
    On Tue, May 1, 2012 at 18:43, Ferenc Kovacs wrote:

    albeit I'm not laruence, but I also supported the idea to keep consistency
    across the allowed params of empty and isset.
    here is my reasoning:
    - both isset and empty are language constructs, which many people use
    almost interchangeability, changing one of them in a way that the same
    expression works with one of them, but blows up with a parse error seems
    wrong to me.
    - maybe you think that isset doesn't really make sense with expressions,
    but don't forget that this patch would also allow constants to be used with
    empty/isset, and imo isset(some_constant); would be useful and maybe more
    straightforward for the people new to the language.

    So isset(UNDEFINEDCONSTANT) will be isset("UNDEFINEDCONSTANT") which will/should
    1) yield a notice, which is unnexpected for isset
    2) return true, which is also unexpected.

    I don't see much point in that.

    Best regards,

    --
    Etienne Kneuss
    http://www.colder.ch
  • Ferenc Kovacs at May 1, 2012 at 7:51 pm


    So isset(UNDEFINEDCONSTANT) will be isset("UNDEFINEDCONSTANT") which
    will/should
    1) yield a notice, which is unnexpected for isset
    2) return true, which is also unexpected.

    I don't see much point in that.
    yep, and if we allow expressions then it is the expected behavior, but you
    are right that this is will change the current standard that isset/empty
    can't raise a notice.
    but this isn't specific to isset, empty will also follow the same pattern.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Xinchen Hui at May 2, 2012 at 1:31 am
    Sent from my iPhone

    在 2012-5-2,3:52,Ferenc Kovacs <tyra3l@gmail.com> 写道:

    So isset(UNDEFINEDCONSTANT) will be isset("UNDEFINEDCONSTANT") which
    will/should
    1) yield a notice, which is unnexpected for isset
    2) return true, which is also unexpected.

    I don't see much point in that.
    yep, and if we allow expressions then it is the expected behavior, but you
    are right that this is will change the current standard that isset/empty
    can't raise a notice.
    but this isn't specific to isset, empty will also follow the same pattern.
    This is really a issue .

    Thanks
    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Patrick ALLAERT at May 1, 2012 at 5:24 pm

    2012/5/1 Ferenc Kovacs <tyra3l@gmail.com>:
    On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov wrote:
    - both isset and empty are language constructs, which many people use
    almost interchangeability, changing one of them in a way that the same
    expression works with one of them, but blows up with a parse error seems
    wrong to me.
    I wish that more wrong usages could blow up with parse errors way
    before waiting for the incorrect line to be run.
    While there is some valid use cases for empty() I see none for
    isset(), it must remain a targeted and specific construct IMHO.
    - maybe you think that isset doesn't really make sense with expressions, exact :)
    but don't forget that this patch would also allow constants to be used with
    empty/isset.
    That is not a very good think IMO.

    For the same reason: this patch would also allow writing: empty( false
    ) or empty( null ) which are both clueless.
    The fact that this patch would now allow syntactically doubtful things
    doesn't mean they should be encouraged nor propagated to isset().

    Cheers,
    Patrick
  • Ferenc Kovacs at May 1, 2012 at 6:34 pm

    On Tue, May 1, 2012 at 7:24 PM, Patrick ALLAERT wrote:

    2012/5/1 Ferenc Kovacs <tyra3l@gmail.com>:
    On Mon, Apr 30, 2012 at 2:39 PM, Nikita Popov <nikita.ppv@googlemail.com
    wrote:
    - both isset and empty are language constructs, which many people use
    almost interchangeability, changing one of them in a way that the same
    expression works with one of them, but blows up with a parse error seems
    wrong to me.
    I wish that more wrong usages could blow up with parse errors way
    before waiting for the incorrect line to be run.
    One could argue that then you should pick a compiled language.

    While there is some valid use cases for empty() I see none for
    isset(), it must remain a targeted and specific construct IMHO.
    I agree that there is less valid use-cases, but I feel that keeping the two
    method consistent about this is more important.

    - maybe you think that isset doesn't really make sense with expressions, exact :)
    but don't forget that this patch would also allow constants to be used with
    empty/isset.
    That is not a very good think IMO.

    For the same reason: this patch would also allow writing: empty( false
    ) or empty( null ) which are both clueless.
    how is that different than for example writing is_null(null) ?

    The fact that this patch would now allow syntactically doubtful things
    doesn't mean they should be encouraged nor propagated to isset().
    we are already have that all over the place, I don't think that this
    particular patch will change anything about that.
    could you elaborate on this part a little bit?
    I mean you can write "stupid" code right now ($null=null;isset($null);
    instead of isset(null);), I can't see how would this patch worsen the
    situation. If anything, the silly code could be understood easier, as you
    wouldn't need to debug the value of the $null variable passed in.
    So I think that
    1, we already too late to prevent that kind of code
    2. even if we could, I don't think that the currently discussed patch would
    really encourage that kind of code
    3, there are/could be valid use-cases for isset
    4, isset and empty should work the same way in regards of the argument
    parsing.

    ofc. this is only my opinion, if I am the minority here, then it is fine
    too, I just wanted to explain what was the reasoning behind that discussion.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Nikita Popov at Apr 30, 2012 at 1:05 pm

    On Mon, Apr 30, 2012 at 9:50 AM, Patrick ALLAERT wrote:
    Hi,

    2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>:
    PS: I added isset() too, to address the consistency concerns mentioned on IRC.
    I would have voted +1 if it didn't contain the isset() change. None of
    the examples used in the isset_with_expr.phpt test seems logic to me.

    Care to explain the consistency concerns here?

    Patrick
    I changed the vote to have three options: "Both empty() and isset()",
    "Only empty()" or "None"

    https://wiki.php.net/rfc/empty_isset_exprs#vote

    Nikita
  • Pierre Joye at Apr 30, 2012 at 8:26 pm
    hi,
    On Mon, Apr 30, 2012 at 3:05 PM, Nikita Popov wrote:

    I changed the vote to have three options: "Both empty() and isset()",
    "Only empty()" or "None"

    https://wiki.php.net/rfc/empty_isset_exprs#vote
    Please post a top thread to notice everyone about this new vote with a
    short explanation.

    Yes, I told you that on IRC a good dozen times since you sent this
    mail here, but there are good reasons why we do so. For one, many do
    not follow any single thread on internals and I would not have noticed
    that mail if I was not on IRC today. So please do it, or the votes
    result, no matter the outcome, cannot be accepted.

    Thanks for your understanding,
  • Laruence at May 2, 2012 at 8:46 am

    On Mon, Apr 30, 2012 at 3:50 PM, Patrick ALLAERT wrote:
    Hi,

    2012/4/12 Nikita Popov <nikita.ppv@googlemail.com>:
    PS: I added isset() too, to address the consistency concerns mentioned on IRC.
    I would have voted +1 if it didn't contain the isset() change. None of
    the examples used in the isset_with_expr.phpt test seems logic to me.
    Hi:
    isset and empty are generally think as a pair, and the both even
    share one ZEND_OP: ZEND_ISSET_ISEMPTY_VAR

    so I think if you want to change empty, you should also change isset.

    thanks
    Care to explain the consistency concerns here?

    Patrick

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Laruence  Xinchen Hui
    http://www.laruence.com/
  • Pierre Joye at May 2, 2012 at 9:10 am
    hi,
    On Wed, May 2, 2012 at 10:46 AM, Laruence wrote:

    so I think if you want to change empty, you should also change isset.
    An expression is not set per se. isset goals, by design, from the very
    1st day, is to test the existence of a variable and a variable only.

    empty() on the other hand, tests if something is empty, and only if it
    is empty. The result of an expression can be empty.

    Cheers,
  • Ferenc Kovacs at May 2, 2012 at 9:36 am

    On Wed, May 2, 2012 at 11:10 AM, Pierre Joye wrote:

    hi,
    On Wed, May 2, 2012 at 10:46 AM, Laruence wrote:

    so I think if you want to change empty, you should also change isset.
    An expression is not set per se. isset goals, by design, from the very
    1st day, is to test the existence of a variable and a variable only.
    "Returns TRUE if var exists and has value other than NULL, FALSE otherwise."

    $foo=null;
    var_dump(isset($foo)); //prints bool(false)

    empty() on the other hand, tests if something is empty, and only if it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at May 2, 2012 at 9:43 am
    hi,
    On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs wrote:

    $foo=null;
    var_dump(isset($foo)); //prints bool(false)
    No offset meant, but it is totally expected and well known, and as far
    as I remember documented too. Assigning NULL to a variable unsets it
    (so to say).
    empty() on the other hand, tests if something is empty, and only if it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.

    Cheers,
  • Pierre Joye at May 2, 2012 at 9:43 am

    On Wed, May 2, 2012 at 11:43 AM, Pierre Joye wrote:
    hi,
    On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs wrote:

    $foo=null;
    var_dump(isset($foo)); //prints bool(false)
    No offset meant,
    lapsus :) s,offset,offense,
  • Anthony Ferrara at May 2, 2012 at 11:37 am
    Pierre,
    On Wed, May 2, 2012 at 5:43 AM, Pierre Joye wrote:
    hi,
    On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs wrote:

    $foo=null;
    var_dump(isset($foo)); //prints bool(false)
    No offset meant, but it is totally expected and well known, and as far
    as I remember documented too. Assigning NULL to a variable unsets it
    (so to say).
    Well, except that it doesn't unset it. It only fails isset(). The
    symbol still exists in the symbol table, and the zval is still
    allocated. That's one reason that isset() can return false, and
    array_key_exists() will return true. But right now there's no way to
    check if a symbol exists since isset returns falls for a null value in
    a symbol (and there's no other way to check it)...

    Not saying it should change, just that it's a corner case that's not
    accounted for in the API...

    I voted for the ability to use an expression for isset() as well,
    since I agree with Ferenc, it's a matter of consistency. Sure, the
    use-case for isset() is definitely weaker than for empty(), but at the
    same token they are definitely related...

    Anthony
    empty() on the other hand, tests if something is empty, and only if it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.

    Cheers,
    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at May 3, 2012 at 5:39 am
    hi Anthony,
    On Wed, May 2, 2012 at 1:37 PM, Anthony Ferrara wrote:

    I voted for the ability to use an expression for isset() as well,
    since I agree with Ferenc, it's a matter of consistency.  Sure, the
    use-case for isset() is definitely weaker than for empty(),
    No, it is not about consistency but goals and meaning. An expression
    is not set or unset. Anyway, that's not something we can argue about
    forever :-).

    Cheers,
  • Lester Caine at May 3, 2012 at 7:17 am

    Anthony Ferrara wrote:
    I voted for the ability to use an expression for isset() as well,
    since I agree with Ferenc, it's a matter of consistency. Sure, the
    use-case for isset() is definitely weaker than for empty(), but at the
    same token they are definitely related...
    I just can't help feeling that it is the wrong use of both. If the function is
    returning a value, then it's returning a value that needs to be used somewhere
    so the work flow handles that. If the function returns nothing instead that just
    seems wrong and needs to be handled better. I'm used to getting back 'false' if
    the function failed and just check for that so why would there be any logical
    reason for using isset or empty to check a function return?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk//
    Firebird - http://www.firebirdsql.org/index.php
  • Patrick ALLAERT at May 3, 2012 at 6:11 pm

    2012/5/3 Lester Caine <lester@lsces.co.uk>:
    Anthony Ferrara wrote:
    I voted for the ability to use an expression for isset() as well,
    since I agree with Ferenc, it's a matter of consistency.  Sure, the
    use-case for isset() is definitely weaker than for empty(), but at the
    same token they are definitely related...

    I just can't help feeling that it is the wrong use of both. If the function
    is returning a value, then it's returning a value that needs to be used
    somewhere so the work flow handles that. If the function returns nothing
    instead that just seems wrong and needs to be handled better. I'm used to
    getting back 'false' if the function failed and just check for that so why
    would there be any logical reason for using isset or empty to check a
    function return?
    Use case:

    // Function definition:
    function getFriends()
    {
    // SQL SELECT or Fetching from XML or Fetching from LDAP or ...
    return $resultsAsArray;
    }

    // Looping on results:
    foreach ( getFriends() as $friend )
    {
    echo $friend["name"], "\n";
    }

    // Case where the results are actually not iterated:
    $amIAssocial = empty( getFriends() );

    1. It it not wrong to return "nothing", like empty sets (empty
    arrays), it is a valid case.
    2. Returning "false" in the case there is no "results" would be a bad
    idea: not only you would have to put a condition in the function
    definition, but you would also require all iterations (e.g. foreach)
    to be encapsulated in a condition statement to prevent looping on
    "false".
  • Herman Radtke at May 3, 2012 at 8:29 pm

    I just can't help feeling that it is the wrong use of both. If the function
    is returning a value, then it's returning a value that needs to be used
    somewhere so the work flow handles that. If the function returns nothing
    instead that just seems wrong and needs to be handled better. I'm used to
    getting back 'false' if the function failed and just check for that so why
    would there be any logical reason for using isset or empty to check a
    function return?
    Use case:

    // Function definition:
    function getFriends()
    {
    // SQL SELECT or Fetching from XML or Fetching from LDAP or ...
    return $resultsAsArray;
    }

    // Looping on results:
    foreach ( getFriends() as $friend )
    {
    echo $friend["name"], "\n";
    }

    // Case where the results are actually not iterated:
    $amIAssocial = empty( getFriends() );
    This is the exact same thing:
    $amIAssocial = !getFriends();


    Earlier, I sent this to Lester only:
    Most people don't realize that an empty array is already falsy so they
    feel the need to use empty. That is the only use-case the RFC gives
    for making this change. From the RFC: "For example if func() is
    expected to return an array, it feels more natural to verify it's
    emptiness using empty() instead of !."
    --
    Herman Radtke
    hermanradtke@gmail.com | http://hermanradtke.com
  • Lester Caine at May 3, 2012 at 8:42 pm

    Patrick ALLAERT wrote:
    2012/5/3 Lester Caine<lester@lsces.co.uk>:
    Anthony Ferrara wrote:
    I voted for the ability to use an expression for isset() as well,
    since I agree with Ferenc, it's a matter of consistency. Sure, the
    use-case for isset() is definitely weaker than for empty(), but at the
    same token they are definitely related...

    I just can't help feeling that it is the wrong use of both. If the function
    is returning a value, then it's returning a value that needs to be used
    somewhere so the work flow handles that. If the function returns nothing
    instead that just seems wrong and needs to be handled better. I'm used to
    getting back 'false' if the function failed and just check for that so why
    would there be any logical reason for using isset or empty to check a
    function return?
    Use case:

    // Function definition:
    function getFriends()
    {
    // SQL SELECT or Fetching from XML or Fetching from LDAP or ...
    return $resultsAsArray;
    }

    // Looping on results:
    foreach ( getFriends() as $friend )
    {
    echo $friend["name"], "\n";
    }

    // Case where the results are actually not iterated:
    $amIAssocial = empty( getFriends() );

    1. It it not wrong to return "nothing", like empty sets (empty
    arrays), it is a valid case.
    2. Returning "false" in the case there is no "results" would be a bad
    idea: not only you would have to put a condition in the function
    definition, but you would also require all iterations (e.g. foreach)
    to be encapsulated in a condition statement to prevent looping on
    "false".
    OK I'm just so used to
    if( $rs = $this->mDb->query( $query, $bindVars ) ) {
    while( $row = $rs->fetchRow() ) {
    }
    }

    So I can't see where 'empty( $rs->fetchRow() )' would fit into the work flow ...

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk//
    Firebird - http://www.firebirdsql.org/index.php
  • Ferenc Kovacs at May 2, 2012 at 11:38 am

    On Wed, May 2, 2012 at 11:43 AM, Pierre Joye wrote:

    hi,
    On Wed, May 2, 2012 at 11:36 AM, Ferenc Kovacs wrote:

    $foo=null;
    var_dump(isset($foo)); //prints bool(false)
    No offset meant, but it is totally expected and well known, and as far
    as I remember documented too. Assigning NULL to a variable unsets it
    (so to say).
    sure, as I quoted the documentation here.
    I just wanted to emphasize, that isset not only checks if a variable is set
    or not, but also checks the value of the variable, which makes your
    argument ("An expression is not set per se. isset goals, by design, from
    the very1st day, is to test the existence of a variable and a variable
    only.") much weaker.


    empty() on the other hand, tests if something is empty, and only if it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.
    yeah, but that wasn't my point, I was saying that an expression can also
    have a value of null, which can be checked by isset, so empty and isset
    isn't any different in that regard for expressions.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Richard Lynch at May 4, 2012 at 6:48 pm

    On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
    empty() on the other hand, tests if something is empty, and only if
    it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.
    Expressions can also return "", 0, 0.0, "0", array()

    You really think those should all be empty?

    Or you want different behavior for expressions vs variables. I'm
    assuming virtually everybody would agree THAT is unacceptable...

    Or are the rules for what is or isn't empty going to also change. Again.
  • Kris Craig at May 4, 2012 at 7:10 pm

    On Fri, May 4, 2012 at 11:48 AM, Richard Lynch wrote:
    On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
    empty() on the other hand, tests if something is empty, and only if
    it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.
    Expressions can also return "", 0, 0.0, "0", array()

    You really think those should all be empty?
    Unless I'm missing something here, aren't all those things already
    considered to be empty?? Here's what the PHP man page for empty() says:

    The following things are considered to be empty:

    - *""* (an empty string)
    - *0* (0 as an integer)
    - *0.0* (0 as a float)
    - *"0"* (0 as a string)
    - *NULL*
    - *FALSE*
    - *array()* (an empty array)
    - *var $var;* (a variable declared, but without a value in a class)


    If that's the way it already behaves, then why would keeping it that way
    even be an issue? If an expression returns any of those things, it's empty.

    I've been following the debate and I'm still a bit unclear as to what the
    benefit would be to allowing non-variables in isset(). I mean, as was
    stated earlier, expressions are neither "set" nor "unset". Furthermore, if
    you were to assign a variable to any valid expression (empty or otherwise),
    it would be considered "set". Therefore, through simple deductive logic,
    would an expression passed to isset() not, by definition, *always* return
    TRUE if the expression itself is syntactically valid? The answer seems to
    be yes as far as I can tell. And if that is the case, then what value is
    there in allowing it if the return value is always the same no matter what?

    --Kris
  • Ferenc Kovacs at May 4, 2012 at 8:27 pm


    I've been following the debate and I'm still a bit unclear as to what the
    benefit would be to allowing non-variables in isset(). I mean, as was
    stated earlier, expressions are neither "set" nor "unset". Furthermore, if
    you were to assign a variable to any valid expression (empty or otherwise),
    it would be considered "set". Therefore, through simple deductive logic,
    would an expression passed to isset() not, by definition, *always* return
    TRUE if the expression itself is syntactically valid?

    yeah, this wouldn't be much to think about if isset in php wouldn't handle
    null values as not set.
    and as I mentioned expressions can return null, so it isn't true that any
    expression given to isset would always result in true.
    but I think we were talked this over already, so not much point repeating
    the same arguments over and over again.

    to summarize, the following cons were brought up against allowing
    expressions for isset :


    - if you pass an undefined constant to isset, you will get unexpected
    result as isset will raise a notice and can return unexpected result as the
    constant is casted to string before being passed to isset(btw. this is how
    expressions work everywhere else, so it isn't a real surprise, but it is a
    change to the current behavior).
    - this is a valid concern, but the same problem applies to empty too,
    so it is a general problem with the current patch/rfc. I think
    it would be
    nice mentioning this in the rfc, as this could/will cause a few
    wtf moments
    for some people.
    - isset(CONST) could be seen as defined("CONST") but they are returning
    different results if CONS is defined with NULL or undefined.
    - this is a valid concern, and there is no good solution, for
    isset(CONST) we either go cosistent with isset or declared, but can't do
    both at the same time.
    - semantically empty can make sense for expressions, isset doesn't:
    - yep, the only thing that makes this a little less clear/obvious is
    the fact that isset in php also checks for value, not only the
    "existence"
    of the variable.
    - following the previous point, there are much more fluent use-cases for
    empty(expression) than for isset(expression)
    - this is true, for null check you should use comparing the value,
    for other cases empty could be much more useful, only the isset(CONST)
    could be useful, but I mentioned the problems with that above.

    after discussing this and thinking it over a few times, I decided that I
    will drop my case about supporting both empty and isset.
    I think that keeping the argument handling for isset and empty in sync
    doesn't worth the possible gotchas.
    and I now a little less sure about suporting this change for empty(), given
    how much do we emphasized over the years that empty won't trigger any
    warning about the non-existent variables.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Kris Craig at May 4, 2012 at 9:18 pm
    On Fri, May 4, 2012 at 1:27 PM, Ferenc Kovacs wrote:
    I've been following the debate and I'm still a bit unclear as to what the
    benefit would be to allowing non-variables in isset(). I mean, as was
    stated earlier, expressions are neither "set" nor "unset". Furthermore,
    if
    you were to assign a variable to any valid expression (empty or
    otherwise),
    it would be considered "set". Therefore, through simple deductive logic,
    would an expression passed to isset() not, by definition, *always* return

    TRUE if the expression itself is syntactically valid?
    yeah, this wouldn't be much to think about if isset in php wouldn't handle
    null values as not set.
    Hmm I'd never really thought about that before. But now that you mention
    it, that does sound like a problem. Honestly, I can see no value in
    maintaining a different "standard" for what constitutes a set or not-set
    variable depending on the function. While I understand Pierre's point that
    people have used $var = NULL; in the past to unset variables, I don't think
    we should actually be supporting that. After all, $var = (anything,
    including nothing) is, by definition, "setting" the variable to something
    (or nothing).

    I would analogize this to a printed dictionary. Let's say you look up the
    word, "glarbofatass". It's not there. So you take out another dictionary
    and look it up again. There's an entry for it, but the entry says, "This
    word has no meaning." In the first dictionary, "glarbofatass" is not set.
    In the second dictionary, "glarbofatass" is set to the state of having no
    meaning. Nevertheless, it *is* set.

    I've never thought of setting something to NULL as being *literally *the
    same thing as unsetting it (though the purpose and end result are mostly
    the same). If we didn't have an unset() function, I might feel differently
    about this. But we do, so really I don't see why "= NULL" needs to be an
    alias for unset(). To be honest, I doubt this would pose any real BC
    breakage, either, unless someone can point me to an instance where somebody
    uses "= NULL" to unset a variable and then checks it with isset() later,
    expecting FALSE.

    Personally, I would consider "= NULL" == unset() but only as it pertains to
    isset() to be a bug that should be fixed, not a "feature" that should be
    preserved. And if we make that change (perhaps target it for PHP 6 since
    it would nonetheless pose a fundamental logic change, albeit an extremely
    minor and low-impact one), then this RFC suddenly makes a lot more sense
    while allowing the scope to be limited to empty() without creating any
    annoying contradictions.

    --Kris
  • Ferenc Kovacs at May 4, 2012 at 9:24 pm


    Hmm I'd never really thought about that before. But now that you mention
    it, that does sound like a problem. Honestly, I can see no value in
    maintaining a different "standard" for what constitutes a set or not-set
    variable depending on the function. While I understand Pierre's point that
    people have used $var = NULL; in the past to unset variables, I don't think
    we should actually be supporting that. After all, $var = (anything,
    including nothing) is, by definition, "setting" the variable to something
    (or nothing).

    I would analogize this to a printed dictionary. Let's say you look up the
    word, "glarbofatass". It's not there. So you take out another dictionary
    and look it up again. There's an entry for it, but the entry says, "This
    word has no meaning." In the first dictionary, "glarbofatass" is not set.
    In the second dictionary, "glarbofatass" is set to the state of having no
    meaning. Nevertheless, it *is* set.

    I've never thought of setting something to NULL as being *literally *the
    same thing as unsetting it (though the purpose and end result are mostly
    the same). If we didn't have an unset() function, I might feel differently
    about this. But we do, so really I don't see why "= NULL" needs to be an
    alias for unset(). To be honest, I doubt this would pose any real BC
    breakage, either, unless someone can point me to an instance where somebody
    uses "= NULL" to unset a variable and then checks it with isset() later,
    expecting FALSE.

    Personally, I would consider "= NULL" == unset() but only as it pertains
    to isset() to be a bug that should be fixed, not a "feature" that should be
    preserved. And if we make that change (perhaps target it for PHP 6 since
    it would nonetheless pose a fundamental logic change, albeit an extremely
    minor and low-impact one), then this RFC suddenly makes a lot more sense
    while allowing the scope to be limited to empty() without creating any
    annoying contradictions.
    then maybe you should open a separate rfc and thread for that.
    btw. $foo = null; doesn't equals/aliases unset($foo); only isset() written
    in a way so that it checks the existence of the variable AND if it exists
    then checks that it's value isn't null.
    maybe this isn't nice for a newcommer to the language, but it is how isset
    works for a pretty long time now, and changing it would be a major BC break.
    not impossible, but that would definitively deserve a separate RFC and
    discussion.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Richard Lynch at May 5, 2012 at 12:22 pm

    On Fri, May 4, 2012 2:10 pm, Kris Craig wrote:
    On Fri, May 4, 2012 at 11:48 AM, Richard Lynch wrote:
    On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
    empty() on the other hand, tests if something is empty, and only
    if
    it
    is empty. The result of an expression can be empty.
    an expression can also have a value of null.
    And NULL is empty. No issue here.
    Expressions can also return "", 0, 0.0, "0", array()

    You really think those should all be empty?
    Unless I'm missing something here, aren't all those things already
    considered to be empty?? Here's what the PHP man page for empty()
    says:
    The following things are considered to be empty:

    - *""* (an empty string)
    - *0* (0 as an integer)
    - *0.0* (0 as a float)
    - *"0"* (0 as a string)
    - *NULL*
    - *FALSE*
    - *array()* (an empty array)
    - *var $var;* (a variable declared, but without a value in a class)
    I am suggesting that some of those wouldn't make so much sense being
    "empty" in an expression.

    empty(2.0 - 1.9999999999999);

    Might not be 0.0, but that's not the point.

    For some not-empty values added or subtracted, more or less at the
    whims of digital float behave would or wouldn't be empty.

    Furthermore, empty on "0" was originally designed user input via
    GET/POST so that an <option>0</option> would be empty()

Related Discussions