> No where in the post is there an example advocating dynamic invocation based on computed strings. No where. Your example that uses a random number generator

> No where in the post is there an example advocating dynamic invocation based on computed strings. No where. Your example that uses a random number generator to select a string and then use that string as a function name is dynamic invocation based on computed strings. > What you're arguing is that you should never send a string name of a function to array_map, but should instead wrap the invocation in a lambda. No, that's not what I'm arguing at all. Your example above uses a string literal, which is basically the same as having a first-class identifier in its place. I don't think that kind of behaviour significantly harms readability. However, there's really nothing more "dynamic" about this kind of invocation than any other invocation in PHP. I kinda question your use of "dynamic invocation" as a blanket term to cover first-class anonymous function application, higher-order functions and indirection. These are all separate-but-related concepts. My cursory Googling didn't turn up any uses of 'dynamic invocation' that are anything like the way you are using it - do you have a source or reference or is this your terminology? > What must it mean deep down for PHP to be able to generate valid opcodes on a pure method call to a method that doesn't exist? It means the internal opcode must simply store the method name as a string waiting to be executed Perhaps I'm misunderstanding what the internals of the PHP interpreter are these days, but you appear to be describing the use of a symbol table or something. The use of 'opcode' confuses me, because if there was code generation going on, it would be possible to statically resolve names to first-class function values. What I'm getting at is that I don't see that there is a difference (in PHP) between the "dynamic invocation" you are describing, and straightforward run-of-the-mill function-calling, given that PHP's internal representation of both is essentially just a string (which is looked up in some symbol table in order to resolve it to a piece of code). And so my point is that there is no real reason to exploit this quirk of language design in order to exploit indirection on computed strings (which, as I said in my previous post, I consider to be a kind of goto-esque spaghetti code feature).