On Thu, 02 Dec 2004 09:09:18 CST, Jesse Pollard said: > On Wednesday 01 December 2004 11:21, Valdis.Kletnieks@private wrote: > ... > > I'm not sure how I feel about that particular conflict resolution - we'd > > have to be more specific about the calling order - would we: > > > > a) Call capable() first, and if it fails, then run the restrictive chain > > b) Call capable() first, and if it succeeds, run the restrictive chain > > c) call Capable(), run the chain, and return (capable || chain) > > d) Run the restrictive chain, and if it fails, call capable() as a last > > resort e) Run the restrictive chain, and if it succeeds, call capable() > > f) Run both, and return (chain || capable) > > Did you mean: f) run both, and return (chain && capable)? > since otherwise, (f) and (c) would appear equivalent. D'Oh! ;) Yes, F and C are duplicates - (chain && capable) *is* another possibility, except it doesn't possess the property that capable will trump chain. (In other words, it's a possible behavior, but not the behavior that Crispin was talking about). Personally, I think "run both and return (capable && chain)" is a reasonable semantic, but I could be overlooking something.. ;)
This archive was generated by hypermail 2.1.3 : Thu Dec 02 2004 - 12:30:50 PST