in reply to File operations "preview" mode?

You can override builtin functions: http://docstore.mik.ua/orelly/perl/cookbook/ch12_12.htm and http://docstore.mik.ua/orelly/perl/prog/ch05_02.htm#PERL2-CH-5-SECT-2.2. Nothing difficult in making them conditional (call of the CORE:: version or printing depending on switch) and even caching (i.e. concatenating to a string that is eval'd eventually and that uses the CORE:: version of the function).

Replies are listed 'Best First'.
Re^2: File operations "preview" mode?
by jh (Beadle) on Aug 26, 2010 at 20:06 UTC

    Hi jethro,

    I do know that it's possible to override core functions and have done so, much to the annoyance of Tom Christiansen, whose "Advanced Perl" seminar I took at USENIX a couple years ago (direct quote: "Don't ever do this unless your sole purpose is to prove how cool you are.")

    Besides the fact that I would also like to override File::Copy and File::Path (and possibly functions from other core modules) this approach is more work and probably more bugs than using a previously-written community-tested CPAN module. :-)

    -jh

      So it sounds like you recognize the impracticality of a "solution" that involves overriding core functions and modules -- even though the "dream module" that you describe in the OP probably couldn't be implemented any other way (as near as I can tell).

      Yet at the same time, it sounds like you are hoping to avoid the alternative of altering every line of existing code (or including a bunch of repetitive stuff with every line of new code) involving any sort of file-system change, so that it can be made conditional on the value of the "preview" option.

      Alas, I don't think there's a third way. The best you can do is find ways to minimize the overhead of making all those file-system operations conditional. Ideally, this is something you plan out for before actually writing any code for the given application.

      In that regard, my personal preference would probably fall toward a module that builds a stack of operations, then, you just check your option setting once at the end of the process, to decide whether to print the stack, or execute it, or present it for approval, or store it as a script file, or ...

      If you're adapting existing code to provide this new functionality, it means editing every line that does a file system call, to turn that into a call to the module's "push" method -- no way around that. If you're starting a new app, it's not that much overhead to write $stack->push( "rename", $arg1, $arg2 ); instead of rename $arg1, $arg2; -- maybe there are ways to make the method call even easier.