|
|
Posted by Oli Filth on 10/24/74 11:45
Jerry Stuckle wrote:
> Oli Filth wrote:
> > Jerry Stuckle wrote:
> >>Oli Filth wrote:
> >>>Jerry Stuckle said the following on 09/04/2006 06:14:
> >>>>That's not what I said. I said if $var is EMPTY.
> >>>
> >>> From the PHP manual for empty():
> >>>
> >>> "The following things are considered to be empty:
> >>> ...
> >>> array() (an empty array)
> >>> ..."
> >>>
> >>Yes, the array is empty. But $var is not! It contains an empty array.
> >
> > No, $var doesn't *contain* an empty array, $var *is* an empty array.
>
> That's YOUR definition.
>
> Most of us understand there is a difference between an empty array and an empty
> variable.
>
> $var = null is an empty variable.
> $var = array() contains an empty array.
Disregarding whether or not we think that *contains* or *is* is the
appropriate word here, nevertheless both of these examples evaluate to
empty in PHP - which I think is the only appropriate criterion for
whether we can consider something "empty".
[IMO, I would define the first one as "a null variable", and the second
one as "a variable that is an empty array". In PHP, "empty" is not a
definition of a variable; it doesn't uniquely tell you what state that
variable is in.]
The term "empty" is, at best, vacuous. $var = 0, $var = NULL, $var =
array() and undefined variables all evaluate to "empty". How can
something that doesn't even exist have measurable state?!
I'm fully aware that the two examples you gave are not identically
equal; they have different types. Nevertheless, with an empty array
(which fulfils the PHP definition of an empty variable), the code I
posted way back works correctly.
Not to mention that even if you do set $var = null, then it still works
correctly, without errors or warnings, and does not alter the original
variable.
> > I thought the purpose was to check for the existence of an *entry* in
> > an associative array, such as $_POST, etc.
> >
>
> Yes, and first you have to ensure the array itself exists.
See below...
> > On the other hand, checking for the existence of a *variable* implies
> > bad practice. There should be no need. You should always know a
> > priori what variables exist at any given point in your code (assuming
> > the wonders of register_globals are disabled).
> >
>
> You really don't understand PHP, do you?
I'll choose to ignore that question....
> Checking for the existence of a *variable* is required for good programming
> practice in PHP. You never know what may have been passed in a GET or POST
> operation, for instance. And you don't necessarily know what may have been
> saved in a cookie or the session.
> Checking to see if these exist is very important in PHP programming!
I'm perfectly aware of that. Validation/checking for existence of
$_POST, etc, members is of course good practice. But you don't have to
check for the existence of $_POST itself.
> >>Yep, and now you have changed the variable, haven't you?
> >
> > Only if it was undefined in the first place, which would be bad
> > practice.
>
> No, it could be perfectly normal. What if the variable you're trying to check
> is $_POST['cblist'], which itself may be an array of checkbox values?
>
> If no checkboxes are checked, the array doesn't even exist in $_POST.
This is one situation I admit I had not thought of. You could validly
use this as an argument for use of a macro here, although IMHO it's a
very limited case, compared to the set of cases which the functional
version deals with fine.
[My technical get-out clause is that the HTML syntax which results in a
sub-array within $_GET/$_POST is actually invalid, and so we can ignore
this case too!]
--
Oli
Navigation:
[Reply to this message]
|