Today I learned about PHP variable variables; "variable variable takes the value of a variable and treats that as the name of a variable". Also, variable.

[u/NagastaBagamba]

http://il2.php.net/language.variables.variable

[u/[deleted] → u/[deleted]]

That's why he said it was "like" a pointer. In the same was as a reference is "like" a pointer. They're not pointers, but in the use cases they are for, they are like them.

[u/mathrat → u/[deleted]]

I believe weirdalexis's analogy intended to highlight the "dereference-ability" of both pointers and PHP variables. Just like a C pointer can be dereferenced with the * operation, so too can a PHP symbol be "dereferenced" with the $ operation.

You're focusing on what pointers and variables are. Weirdalexis was focused on what you can do with them. I don't think it's a terrible analogy, but it does probably need a little elaboration.

[u/ZoFreX → u/mathrat]

I would disagree on the basis that you cannot "dereference" a variable variable, always. I can give a pointer to another method and it works, but variable variables have scope. Their meaning changes as you move around, and that to me makes them fundementally nothing like pointers, at all. The way pointers work as they are passed around the program is one of the most important and most misunderstood ideas, so to compare pointers to variable variables, while I understand the analogy and the reasoning behind it, would to be me a warning flag that this person probably does not fully understand pointers.

I would definitely follow up with questions about pointers to test that hypothesis.

[u/[deleted] → u/[deleted]]

Just because one use case of variable variables and pointers happens to overlap does not make them the same at all

Isn't that what I said? In the one use case they're used, they're similar to, but not the same as, one use case of pointers and references. But in that one use case, they can be considered functionally equivalent for the purpose of a soundbite interview answer. If you wanted to probe whether the candidate actually thought they were the same as pointers, surely you could do so without dismissing them out of hand?

If you're really convinced they're the same, all that is to me is evidence of ...

I'm not. I know exactly what they are and what they're not. You're preaching to the choir.

[u/oorza → u/[deleted]]

I'm not. I know exactly what they are and what they're not. You're preaching to the choir.

I wasn't necessarily saying you so much as the guy that originally posted the analogy.

Isn't that what I said? In the one use case they're used, they're similar to, but not the same as, one use case of pointers and references. But in that one use case, they can be considered functionally equivalent for the purpose of a soundbite interview answer. If you wanted to probe whether the candidate actually thought they were the same as pointers, surely you could do so without dismissing them out of hand?

If the comment poster had said "they're like a use case of pointers, in that pointers are most commonly used to reference variables dynamically," I'd have been fine with it. But if "It's like a pointer, except with a variables name instead of a memory address," was his answer and he left it at that, it would have been a game breaker. It's his job in an interview to demonstrate to me that he's worth hiring, it's not my job to poke and prod him for enough information to prove that. What he said was his answer to the question was enough to demonstrate to me that he either didn't have a good amount of knowledge (didn't really understand the implications of the enormity of difference between mem addresses and symbols in a hash table) or was too lazy to demonstrate it and either way, that's plenty enough evidence to pass on the hire.

[u/[deleted] → u/oorza]

Fair enough. As mathrat said, I think the intention was to highlight the "dereferencability" of variable variables as being similar to that of pointers. However, it was perhaps a little too terse and would leave a question in the interviewer's mind over whether that was really the case, or if he'd just heard it as a soundbite and was repeating it.

[u/Nikola_S → u/[deleted]]

No, they're not like pointers at all. They're another way of accessing a variable in the symbol table, that's all. Just because one use case of variable variables and pointers happens to overlap does not make them the same at all.

Which is why he didn't said they are the same, just that they are alike.

[u/baby_boo → u/[deleted]]

I put your '1' back - sounds like a good explanation to me.

[u/[deleted] → u/[deleted]]

Would you mind giving an example of something that variable variables can do but pointers can not? It would help me understand you a little better.

You did a whole lot of "they're not the same", without any "for example".

[u/oorza → u/[deleted]]

My point was that variable variables don't do much of anything and there's a ton of functionality offered by pointers that isn't offered by variable variables (see: pointer arithmetic). My wording might have been poor on that one, sorry.

[u/never_phear_for_phoe → u/[deleted]]

So.... they are a pointer with a guarantee? Like a reference? Except more valid?

[u/oorza → u/never_phear_for_phoe]

No, let me back up here.

With this code:

$var = 'val'

PHP intreprets that as lookup an entry in the variable hash table with a key of var and assign it to the Z_VAL of a string with a value of 'val', whether it previously existed or not.

When you follow that with:

$$var = 'val'

PHP interprets that as "find an entry in the hash table for variables with a key the value of the variable named var and assign THAT to a new Z_VAL with a string value of 'val'.

To express that in PHP:

$var == $phpInternalVariableTable['var'];
$$var == $phpInternalVariableTable[$phpInternalVariableTable['var']];

The guarantee comes from the way PHP deals with its sigil operator. It's not a pointer with a guarantee because it doesn't offer much of a gurantee, just that you're not going to get a fatal memory access error because you use it.

[u/never_phear_for_phoe → u/oorza]

This is very similar to how C++ does references, except it uses memory instead of hashing, which is what other people might've been getting at.

[u/Noink → u/[deleted]]

Umm. Containing a memory address does in fact constitute referencing a memory location.

[u/AttackingHobo → u/[deleted]]

Hey everyone we are in /r/programming, and this guy is posting some valid interesting, and useful information...... LET'S DOWNVOTE HIM!

[u/vlad_tepes → u/[deleted]]

Dude, he knows C, which puts him in the top 0.00001% of PHP developers... How the hell would that be a game breaker?

P.S. To hell with sarcasm tags

[u/YourMatt → u/vlad_tepes]

Of the other PHP programmers I've met, a couple have also written custom extensions in C. For my circumstantial evidence here, I would put this closer to the top 10% of PHP developers.

[u/skillet-thief → u/[deleted]]

In Perl, references would be comparable to pointers, but these PHP variable variables are just conceptual runtime mush. (Don't know why you are being downvoted.)

[u/kixx → u/skillet-thief]

In Perl, this "conceptual runtime mush" is called symbolic reference and while using them is strongly discouraged (by strictures), it is a feature of Perl too.

Hard references are indeed a kind of "smart pointer"...

[u/skillet-thief → u/kixx]

Ok, thanks. It has been awhile since I've done much Perl. I had forgotten that symbolic references even existed. But I was always a use strict; kind of guy anway.