> > 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.
>
> In your code docs you have the following bit of pseudo code:
>
> unless (ENSURE) {
> USING;
> die unless ENSURE;
> }
>
> From that I am assuming that an ensure statement is something you want
> to be true *after* your statement is run, but *not* before it (and if
> it is true before, then the statement is not needed). I think the
> pre-condition (at least from my POV on the subject) would work
> something like this:
>
> die unless PRECONDITION;
> unless (ENSURE) {
> USING;
> die unless ENSURE;
> }
>
> However, there are times when it might make sense for that
> pre-condition block to be post-ensure, if it were only guarding the
> using statement, but I could imagine cases when it would make sense to
> guard the ensure statement as well. Maybe you need 2 types of
> pre-conditions? One for guarding ensure and another for guarding the
> entire step. Although maybe something like this would work.
I'm a little confused as to why one would need pre- and
post-conditions at all. The "ensure" block would seem to handle the
whole thing as it is both the pre- and post-condition to the "using"
block. (What about aliasing "doing" to "using"?)
The only thing I can see being useful is allowing for more than one
"ensure" and more than one "using" block. This would allow me to write
something like:
step Foo =>
ensure { -f '/net' }
ensure { -f '/net/foo' }
ensure { The actual thing I care about }
using { Do something here }
using { Do something else here}
;
The benefit is that you can do things like:
sub foo { blahblah }
sub bar { blahblah }
step Foo =>
ensure \&foo
ensure \&bar
using { Do something }
;
And have reusable ensure clauses. Sure, you could do:
step Foo =>
ensure { foo() && bar() }
using { Do something }
;
But, there's no reason not to allow it, that I can think of. This is
especially true when treating them as assertions.
*thinks a little bit*
> > 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.
>
> IMO lack of them is programmer error, and should throw an exeption.
> What is the use of using your framework but to use the ensure and using
> directives and get those benefits? Otherwise are you not just adding
> several levels of indirection for a subroutine call?
I agree that ensure should always be there. using not being there ...
*shrugs* - not so big a deal.
> I also have a feature suggestion for you, as this is something I
> recently ran into. How about the ability to have a timeout on the
> block? I recently had a problem where a cron job was hanging for about
> 8 hours because a very odd condition occurred which caused a subprocess
> to require user input. The result was that everything seemed to report
> success, but the process was not yet complete (and so couldn't fail and
> tell me what was wrong). Not until I checked the output of top did I
> see what was wrong. No granted it was my own stupid fault (I am mostly
> a programmer, and I am a mediocre sys-admin at best), but a timeout on
> that particular block of code would have been nice.
I like the idea of a "no_longer_than" with a prototype of ($@) that
takes a number of seconds to run. Alternatively, you could use a
format of /\d+[A-Za-z]?/ and allow things like 30m, 2d, 12h, 3600s,
etc.
********
NOTE: One thing that you need to be aware of is the potential for
memory leaks and other problems using the & prototype. See
http://www.perlmonks.org/?node_id=278900 for more info.
********
_______________________________________________
sw-design mailing list
[EMAIL PROTECTED]
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
