$_SESSION['ip'] = ’127.0.0.1′;
$var = ‘ip’;

echo $_SESSION[$$var]; // echoes nothing
echo $_SESSION['ip']; // echoes 127.0.0.1

help?

While it will be some time before the distinction carries much weight with my studies, .01% worth of ambiguity now could turn into a substantial habitual error for me later on.

Thanks Elias (and Dajve).

> @Dajve Working with references is also something which requires real life examples to make the user aware of its use.

I understand that working with references is not something to go into in this guide, it was just to illustrate the fact that there is a real difference between a variable being unset and being set to null. My point is simply that stating
“// The $new_items variable doesn’t exist now
$new_items = null;”
and
“unset() is a PHP function that is the same as doing $player_name = null;”
is inaccurate and misleading, especially for a beginner who may be encountering this for the first time.

> Your ‘it is just null’ statement makes sense, but what about undeclared variables, they are null too? They’re even identical according to ===.
Undeclared variables aren’t null but they do evaluate to null, hence the results are identical; the fact that PHP will trigger an “undefined variable” notice shows that there is a problem with the statement. Also, the existence of both is_null() and isset() functions shows the two types should be dealt with discretely.

Teaching a beginner that this is a valid method of working with variables is, in my opinion, somewhat irresponsible. For example, a developer who disregards the undefined variable notice because he’s grown accustomed to it appearing when working with null values is going to have a much harder time troubleshooting should he make a typo in a variable name becuase he’s already disregarding that message.

As I say, I do think this is a useful primer for beginners, but there is an important distinction between something which exists and something which is null. For an article geared towards this level of developer, it’s enough to make the reader aware of this fact without going into details; the problem I had is that you explicitly state the opposite on two occasions.

To give a real world example, it’s the difference between having an empty cup and not having a cup at all. Most of the time you’re concerned with the contents of the cup, which evaluate to the same thing (neither the empty nor non-existent cup contain anything). In the future, though, believing that there is no difference between the non-existant (unset) and empty (null) cups because that’s what you were taught can lead to a horrible mess when you try to pour water into something that isn’t there.
OK, so that’s a slightly silly analogy but my point stands: despite the fact that, in most situations, you’re more concerned by the fact you have no coffee rather than whether there is a cup there or not, there is still a difference between the two states.

> See the ‘Data Type Switching’ where the user is warned for the expensivity of type switching. I could and probably should have included your point though.

Re: the difference between (unset)$foo and unset($foo)? That was more an incidental point about the quirkiness of PHP – to be honest, I can’t understand the inclusion of an (unset) typecast, especially one that works differently to the unset() function, so I never use it. But that’s a separate discussion – just thought it was the kind of point that belonged in the comments for those of us who read this far =o)

Anyway, that turned out longer than I expected! Don’t think I’m having a pop at what is a good article overall, I was just burned by incorrect statements of fact when I was starting out and know the difficulties trying to troubleshoot with false assumptions.

Dajve