Danek Duvall wrote: > On Tue, Sep 09, 2008 at 10:13:41PM -0500, Shawn Walker wrote: >> A stack doesn't solve all the problem either though. >> >> A stack only solves the situation where: >> >> A starts, B starts >> B ends, A ends >> >> ...if B ends after A ends, a stack doesn't work. > > True. Though given that end_operation() doesn't take an operation name (or > a handle returned by start_operation), then there's no way to detect the > non-stack case. At best you can keep a depth count, which is one reason I
I originally had implemented start_operation (I've been through three almost complete implementations of history already before I posted the webrev) based off a dict, where you had to tell it which operation you were starting and which you were ending. However, that made exception handling not so pretty, since it means that I had to litter calls to end_operation() all over. I mainly took the current approach because it was very clean at the cli level -- it was easy just to end whatever the current operation was upon exit. However, as you pointed out before, it is conceivable that we could have multiple operations occur at the same time in the future. > suggested a stack. Another is that while a stack of operations makes some > amount of sense, a non-stack doesn't, as far as I can tell. It simply > indicates programming error. Again, I dunno if you can ever tell, so for > the paranoid, erroring out when you start a second operation before closing > out a first is really the only thing to do. I'd like not to be that > paranoid, but it's up to you. I'm assuming what you're saying here is that it only makes sense to: start op A, start op B end op B, end op A ...any other usage pattern is simply programming error? I can live with that or simply requiring passing the name of the operation being ended to end_operation(). Like you said, I'd rather not error out when I start a second operation before ending the first one. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
