Ah sorry, I forgot to add to my statement below that, in standard rebol functions, you can't get mutually exclusive refinements, because nothing is stopping you specifying them together. (unless a hand comes out of the monitor and physically prevents you typing them. :)
I wanted to point out that Izkata might have better said: "mutual refinements *handled* exclusively". Anyway, Anton. > Anton: > > > "Mutually exclusive refinements" should mean: > > you don't get any (= exclusive) > > if they are specified together (= mutually). > > That's a logical response. But it's not the only logical response. > > Take an example: a function whose job it is to adjust a date to > the nearest > Monday (start of week) or Saturday (start of weekend). > > It is obvious what it should do if I invoke it "properly": > nearest-to/sow now/date > or > nearest-to/sowe now/date > > But what if I code? > nearest-to now/date ;; no refinement > or > nearest-to/sow/sowe/date ;; both refinements > > Possible responses include (there are many others): > -- function crashes with or without logging an error message > -- function returns none or false > -- function returns input date unchanged > -- function defaults to /sow -- so I get the nearest Monday > -- function works out both /sow and /sowe. Then it returns the > earliest one, > so I get a Monday or a Friday > > All of those are reasonable behaviours under some conditions. But > unless you > know the usage the function was *initially* intended for, it's not really > possible to guess what default behaviour my actual, real, > nearest-to function > displays. > > Of course, it might make a lot more sense, and remove a lot of dangerous > guessing, if it had been initially written as two separate functions. > > Sunanda. -- To unsubscribe from the list, just send an email to rebol-request at rebol.com with unsubscribe as the subject.
