It can. Python, for example, builds up classes at runtime. PHP builds up classes at compile time. There are plenty of other examples. PHP is really dynamic through eval() but that's more rare.

Although PHP does support the above syntax, it's actually pretty rare in production code. PHP can be optimized like JavaScript is: perform direct variable/member access but provide a slow path for these kinds of dynamic lookups.

You can't just wave away the impact of having eval though. Just the fact that it exists means you need to keep around some supporting state like variable names. You can't do full constant folding and eliminate all intermediate steps for example if there a chance a runtime-created code will reach into your frame and want them back.

eval() is scoped to the current block. If you even just ignored JITing any function with eval() in it then you'd still get quite far.

Similar things are done by JS engines and others nowadays. They optimize and keep the original stuff in case assumptions stop holding.

You can do this in PHP:

    <?php
    eval('class Hello {public static function you(){echo "Yes!";}}');
    Hello::you();

or this:

    <?php
    file_put_contents('c.php', '<?php class Hello {public static function you(){echo "Yes!";}}');
    require('c.php');
    Hello::you();

Thus generating a class at runtime-ish.

I used to use that pattern $$ frequently for library code.

I wish PHP had classes spread across several files like ASP.NET.

The PHP way for that is Traits

I think he means partial classes in C#. Great for code generators.

That looks it merely needs some reflection support (variable name lookup).

The whole point of a JIT is that you don't do naive variable name lookup.

With a proper intermediate representation you'd connect that $$ variable lookup directly to the original variable's edge.

Isn't reflection slow as hell?

If not please correct me.

It's less fast than direct lookups, but if the compiler supports it properly, it shouldn't be any slower than a associative array lookup.

  echo $FOO[$BAR];
  echo $$BAZ;
  >>>
  
  push FOO.ptr
  push BAR.ptr
  call hash_get
  push ax
  call print
  
  push local_table // static per compiled scope
  push BAZ.ptr
  call hash_get
  push [ax+24] // entry->value
  call print

You'd probably want to add error handling (to both cases) and accessing a global variable that didn't exist when the code was compiled will likely be slow, but if becomes a preformance bottleneck you can always rewrite it to something easier to compile.

And of course a smart JIT compiler can even put the variable access lookup in an inline cache on the function so that in the future it's a direct type + key = offset calculation rather than a memory lookup and the hash_get call is avoided.

True. I was aiming for the simplest example that could pass as real general-case-ish assembly; there's plenty of room for improvement.