Didn't intend to cause harm in "straw-man"ing. I think it's valuable to know where people are coming from. You care enough about programming languages and verification to have a blog on it, that's awesome. It's perspective.
No where in the post is there an example advocating dynamic invocation based on computed strings. No where. In fact, the more I read your responses the less I believe what you're saying has anything to do with the contents and examples of the post. We're on the same page here: dynamic invocation with computed strings: bad. spaghetti code. evil like eval.
> What does "dynamic invocation" have to do with higher-order functions?
Everything? Whether you're rolling your own or making use of PHP's built-in higher order functions, like array_map http://us.php.net/array_map, you're dynamically invoking something: a lambda, a function, an instance method, or a static method. Unfortunately these are distinct things in PHP. So with array_map its first argument is a callback, or something that returns true to is_callable as described in the post. 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. So..
Point blank, it's just not in PHP. It's more than twice as slow, it takes more than twice the memory, and, most importantly is every bit as unsafe. Notice I misspelled lower with an extra w? Let's imagine that's a bug, a programmer's typo. Neither case will error out until array_map is executed which means both parse and generate opcode just fine. Reconsider the function call wrapped with in a lambda. 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. So once we hit the op a table lookup based on a string in your code happens. Both ways. One string is wrapped in quotes, the other in a far more elaborate construct.
As for reflection, I'm all for it but in PHP a reflected function or method object is not a callable, thus cannot be passed to a function like array_map. Even if you could, I do not believe that, in PHP, the following is any less evil:
Again, more memory, more code to execute, won't error out until runtime.
I really don't think you or I disagree on anything in terms of "best programming practices". The only thing we seem to disagree on is what this post was about and trying to demonstrate/advocate.
> 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).
No where in the post is there an example advocating dynamic invocation based on computed strings. No where. In fact, the more I read your responses the less I believe what you're saying has anything to do with the contents and examples of the post. We're on the same page here: dynamic invocation with computed strings: bad. spaghetti code. evil like eval.
> What does "dynamic invocation" have to do with higher-order functions?
Everything? Whether you're rolling your own or making use of PHP's built-in higher order functions, like array_map http://us.php.net/array_map, you're dynamically invoking something: a lambda, a function, an instance method, or a static method. Unfortunately these are distinct things in PHP. So with array_map its first argument is a callback, or something that returns true to is_callable as described in the post. 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. So..
Is preferable to: Point blank, it's just not in PHP. It's more than twice as slow, it takes more than twice the memory, and, most importantly is every bit as unsafe. Notice I misspelled lower with an extra w? Let's imagine that's a bug, a programmer's typo. Neither case will error out until array_map is executed which means both parse and generate opcode just fine. Reconsider the function call wrapped with in a lambda. 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. So once we hit the op a table lookup based on a string in your code happens. Both ways. One string is wrapped in quotes, the other in a far more elaborate construct.As for reflection, I'm all for it but in PHP a reflected function or method object is not a callable, thus cannot be passed to a function like array_map. Even if you could, I do not believe that, in PHP, the following is any less evil:
Again, more memory, more code to execute, won't error out until runtime.I really don't think you or I disagree on anything in terms of "best programming practices". The only thing we seem to disagree on is what this post was about and trying to demonstrate/advocate.