|There's more than one way to do things|
Re^4: "Practices and Principles" to deathby BrowserUk (Pope)
|on Mar 01, 2008 at 04:05 UTC||Need Help??|
I'm not sure bounding in like a bungee boss and saying "I'm here to challenge the status quo! The prevailing wisdom doesn't always work!" is the way to do that, which is why I responded to BrowserUk so strongly.
Unfortunately, as is so often the case, you were so busy responding strongly, that you either: a) didn't bother to read what I wrote; or b) read it, and decided that it was easier (or perhaps, more entertaining) to take minutia of my posts and blow them out of proportion, than to deal with the argument itself.
For example. Read back and you'll find that string eval was just supporting example to a wider point--accusation if you prefer--that, despite recognising the importance of test code, by using the Test::* modules to create test suites,
I do not have a problem with the use of string eval--subject to sensible precations. As I've pointed out before, and I seem to recall but cannot find, you may have done similar, when you get down to base level, all Perl code is handled through string eval: use is require is do is eval. Only two things differ. The source of the string and the timing of the evaluation.
Indeed, I've spoken up against the unthinking paranoia--"if you cannot trust the source of the code it can be dangerous; if you repeatedly evaluate the same code, it can be slow"--that surrounds string eval, being converted into "string eval is evil", on many occasions in this place. Provided the code being evaluated originates from within your own filesystem/organisation, and is provenanced with the same credentials, there is no greater risk between evaluating that code at runtime, and evaluating a perl source file at compile time.
And provided that you do not evaluate identical code more than once, (think Memoize or a hash lookup), then it is no slower than doing the same thing at compile time. And far faster than trying to replicate the Perl parser using Perl code (C vs. Perl) or (for example) Parser::RecDescent.
And it is this last point that I was making about Test::Builder's use of string eval. If you are, at the lowest level, going to kick the responsibility of performing a comparison test off to Perl's parser (via string eval), why bother with interspersing all the layers between those comparisons and the Perl parser? You mentioned that you had attempted a dispatch table solution but that string eval proved to be faster. You also challenged me (though I'm pretty sure it was more of a dare than a challenge), to suggest an alternative that would deal with all the edge cases and caveats that had been evolved into T::B. Well, here is an idea for you: Let Perl do it
How? How about this? (And I know before posting that you will find a reason for not using it (based upon my crude implementation. Perhaps something to do with supporting ancient builds?):
As far as I am able to discern, as the code will be run with the context of the calling code, the interpretation of any variables--be they tied, overloaded or whatever--should be identical to the way they would be interpreted if executed at the same point in the calling code. Assuming that you arrive at similar conclusions, no doubt you'll let me know if not, then go back and look at the shenanigans that similar code goes through before being passed back to string eval. And also consider the less than stellar syntax that it requires.
One possible objection to this is that it cannot (easily; ignoring B::* for the moment), automatically produce a comment that shows the exact code. I have two answers to that:
But my primary objections to Test::*, are:
I do not expect a meaningful response to this, because that would require you to actually consider my arguments rather than using spoiling tactics, like exploiting a typo , to dismiss them.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.