Greetings, I joined this list after my module was first mentioned here. I'm amazed, honestly, that folks are actually looking at it, rating it on CPAN, posting bug reports, and asking me questions about it (only some of which are RTFM or feature requests ;-) -- I thought it was just this kooky idea that might only match the way I think about scripting. Apparently not!
Anyway, as to the question of preconditions--it seems to me that the right way to implement them is as a new step block, and either "presuming" or "assuming" is the right word. So: step withPrecondition => ensure { -d '/net/scratch' } presuming { -d '/net' } using { mkdir "/net/scratch" } ; I assume that C<presuming> would not be checked if the C<ensure> block succeeded, but I'm willing to hear arguments to the contrary. I've been thinking about what to do if either the C<ensure> or the <using> blocks are missing. Currently the module throws an exception, but I don't think that's right. In an earlier draft of the module, I had an "ALWAYS" variant that ran the C<using> clause whether or not the C<ensure> was present. Surely step withoutUsing => ensure { -f '/boot/vmunix' } ; should be treated as an assertion: if it's true, go on, if false, throw an exception. But step withoutEnsure => using { mkdir "/net" } ; seems somewhat useless to me. Considering the fact that other blocks may exist (sanity/rollback/etc.), perhaps a missing C<ensure> should be treated specially so it fails before C<using> and succeeds after. In that case step withPre => presuming { -d "/net" } using { mkdir "/net/scratch" } ; Would run equivalently to { die unless -d '/net'; mkdir "/net/scratch"; } I still don't have the ALWAYS variant allowed for here, though. What I need is a postcondition block. What I'm blocked on is a name that is sufficiently declarative--i.e., step withPost => using { mkdir "/net/scratch" } WHAT? { -d "/net/scratch" } ; That screams for C<ensure>, but that word's already taken. I'm a little bit like Larry in that I think naming is terribly important and much more often get stuck on finding the right name than on finding the right semantics. :-) Perhaps someone has a suggestion? -- Trey Harris Vice President SAGE -- The System Administrators Guild (www.sage.org) Opinions above are not necessarily those of SAGE. _______________________________________________ sw-design mailing list [EMAIL PROTECTED] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design