Re^2: TDD of non-module code

[davies]

Your suggestion regarding do looks very interesting. But to go through your points in order:

My concern about "exposure" (which might not be the best word) is that either I would have to use something like Exporter and end up with sub names in a namespace where I haven't planned for them to be (risking unintended consequences) or I have to use namespace::sub to call them. Maybe it's just prejudice on my part, but this doesn't appeal to me. I can't express my reservations clearly, but I feel uncomfortable doing it.

As far as adding another level of indirection is concerned, I have no difficulty describing my reservations! :-) I am already passing references around in such a way that leads to code like if (defined $${$${$hashref}{'refTextAry'}}[0]) {. In a separate file, I have over 100 lines of code explaining to myself just why this works. "Just one more level of indirection" fills me with terror. I really wouldn't trust myself to be able to write working tests.

I am definitely interested in do, though. Unfortunately, the docs seem confusing, at least at first glance.

do EXPR

Uses the value of EXPR as a filename and executes the contents of the file as a Perl script.

do 'stat.pl';

is just like

eval `cat stat.pl`;

isn't a good start for me. The only time I've met cat is as the Unix equivalent of type, which seems to contradict "executes ... a Perl script". Your explanation seems far clearer, but I'll have to do some experimenting to find out what is and isn't possible.

Thanks & regards,

John Davies