3 ms·

Your example of adding a comment mentioning the methods called in there would indeed pass the Grep Test, and is a reasonable compromise when there is a real cal

by phleet 13y ago

Your example of adding a comment mentioning the methods called in there would indeed pass the Grep Test, and is a reasonable compromise when there is a real call for dynamic declaration. I think there are definite ways of adding metaprogramming functionality without breaking this test. For instance, in the first JavaScript counterexample, if the iteration was over [{attr: "position", fn: "getPosition"}, {attr: "direction", fn: "getDirection"}] instead, the Grep Test passes, and you get much of the same benefits, with a very minor duplication that I'd argue is worth the cost.

MDCore 13y ago
So update your blog post to say that. I had the same reaction as GP.
- phleet 13y ago
  Done.
jerf 13y ago
I work in Perl for the most part, and the alternative I've been using lately for functions is to assert that for a given generated sub, the text 'sub routine_name' exists literally in the code somewhere. This takes two forms in my case: my %to_generate = ( 'sub first' => { ... }, 'sub second' => { ... } ); generate_from_spec(%to_generate); generate_from_spec then strips off the 'sub ', and errors out if it is not found. The second case I have is a function that itself then generates a function, but is trying to look like a sort of normal function itself, in which case I end up with: generate_sub routine_name => ... whatever arguments ... "abusing" Perl's => operator, which functions like a comma except that it forces stringification of the left argument, to once again make the literal, greppable "sub routine_name" appear in the codebase. Here "routine_name" is then just a standard string argument, the alterative being generate_sub "routine_name", which is then harder to grep for. (Still possible, obviously, with a different grep query, but only if you already know up front you need to add the other possibilities.) Note this actually goes a step beyond what you are proposing in that it makes the declaration site clear; my counterproposal for your JS case would be ["function getPosition", "function getDirection"].each(...) and using string manipulation to do whatever you need to do to get the right info out of the function name.

by phleet 13y ago

MDCore 13y ago

So update your blog post to say that. I had the same reaction as GP.

phleet 13y ago
Done.

jerf 13y ago

I work in Perl for the most part, and the alternative I've been using lately for functions is to assert that for a given generated sub, the text 'sub routine_name' exists literally in the code somewhere. This takes two forms in my case: my %to_generate = ( 'sub first' => { ... }, 'sub second' => { ... } ); generate_from_spec(%to_generate); generate_from_spec then strips off the 'sub ', and errors out if it is not found. The second case I have is a function that itself then generates a function, but is trying to look like a sort of normal function itself, in which case I end up with: generate_sub routine_name => ... whatever arguments ... "abusing" Perl's => operator, which functions like a comma except that it forces stringification of the left argument, to once again make the literal, greppable "sub routine_name" appear in the codebase. Here "routine_name" is then just a standard string argument, the alterative being generate_sub "routine_name", which is then harder to grep for. (Still possible, obviously, with a different grep query, but only if you already know up front you need to add the other possibilities.) Note this actually goes a step beyond what you are proposing in that it makes the declaration site clear; my counterproposal for your JS case would be ["function getPosition", "function getDirection"].each(...) and using string manipulation to do whatever you need to do to get the right info out of the function name.