Hacker News Reader

Comment by maxxxxx | Hacker News Reader

It's not a great practice but super common. I have seen code like

$i = "j": $$i = 3;

WTF?

This isn't all that uncommon in C. It's not really fundamentally different than pointers to pointers, just a slightly different syntax:

    int a = 1; int *b = &a; *b = 2;

If this can be compiled to efficient assembly, I don't think that kind of variable binding presents much more of a challenge.

The content of the $$ is a string so it can be anything including invalid variable names or unknown variables. There is nothing the compiler can do. In C it's totally deterministic.

This isn't true: a C program could read a pointer address from the user, convert it to an int and store it in the two-star pointer, then dereference it (this is essentially what gdb's `x` command does).

All this is essentially a double hashtable lookup (assuming the lexical environment is implemented as a hashtable, but if it's something else, it's similarly trivial):

    environment[environment["i"]] = 3

People have been compiling extremely dynamic languages since the Lisps, at the very least; and, assembly itself isn't really a "statically typed" language.

Such a program invokes undefined behavior and thus isn't a correct C program.

Hmm, as far as I can tell, if you cast an appropriately sized unsigned integer to a pointer type and then dereference the pointer, the result is only UB if the integer isn’t the address of an initialized memory location compatible with the target pointer type.

In C the variable to be dereferenced can be uninitialized or it can result in a segfault. $$ is similar though the potential space indicated by an arbitrarily long string of characters is much larger than the potential space indicated by an integer or long - really I think PHP has an advantage here since it only needs to reference it's internal symbol table which it has full control over vs. memory at large where an erroneous symbol could actually be in a program's data memory and look like it's correct - a typo'd var var would have to be either a valid symbol name or necessarily be known to be bad.

You just have the compiler add all local variables into a dictionary of pointers keyed on the variable name whenever $$ appears in scope. Then compile all $$ as the dictionary lookup.

The fact ${anything interpreted as a string} exists is what makes php great and awful at the same time. It let you do things which will demand a lot of contrived patterns, classes and interfaces in other languages. But it also mean you usually end with some nightmare to maintain full of security holes.

Yeah, I would never hire someone using dynamic variables, any occurrence of "$$" is a no-no and just denotes poor engineering.

I think if PHP is the only language you know this pattern probably feels extremely elegant. The JS guys also like to do stuff like this.

Just wait until you meet dynamic dynamic variables, nothing more elegant than that...

    $x=0;$a='x';$b='a'; echo $$$b;

Haven’t seen that one in the wild. Can that chain just keep going?!

Not sure how long .. but the chain can be quite long!!

    $x = 'y';
    $y = 'x';
    echo $$$$$$$$$$$$$y;

I've tested with 1500 `$` and it still works :)

Good to know that this method scales well ;).

Lazy coder here :

    foreach(['a' => closureA, 'b' => closureB, 'c' => closureC] as $name => $toApply) {
      $myObject->${convertNameToFieldName($name)} = $toApply($something);
    }

Too clever by half - a textbook example. This is, in essence, write-only code.

I write a lot of JS (read: TypeScript if I have any say in it) for work so I’m probably a JS guy.

I hate stuff like that. It breaks more than it helps. It overcomplicates trying to dance your way through reasoning what is actually happening. It’s unreliable and I hate it.

Carry on...

Reply on news.ycombinator.com