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

Reply via email to