True enough. Your argument for including the savebefore as a pair of flags
is good; I'm convinced.
Looking at the savebefore flags, it would be easier to set and evaluate them
if these were the flag values:
jobSaveBeforePrompt=0, // default
jobSaveBeforeYes=768,
jobSaveBeforeNo=256,
jobSaveBeforeMask=768
Then you check (flags & jobSaveBeforeMask) and you get either yes, no, or
prompt, with prompt being the default behavior. And to set it you would do
this:
int saveBefore = jobFlags & jobSaveBeforeMask;
if (optValue == optYes) {
saveBefore = jobSaveBeforeYes;
} else if (optValue == optNo) {
saveBefore = jobSaveBeforeNo;
} else if (optValue == optPrompt) {
saveBefore = jobSaveBeforePrompt;
}
jobFlags = (jobFlags & ~jobSaveBeforeMask) | saveBefore;
That would follow the DRY principle without the regression that was in your
version #8. What do you think?
Cheers,
Bruce
"April White" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Bruce Dodson wrote:
>
>>I do think it makes more sense to keep the saveBefore separate from the
>>flags, because saveBefore is not used by the job subsystem; saveBefore is
>>applied "before" the job is placed in queue.
>>
>>With or without that change, here is a further refactoring of the good
>>work you've done to remove some repetitions from the code. Among other
>>things, the new version smooths out the discontinuity between yes / no and
>>the other option values. This version also fixes a regression in the
>>save-before handling: in case of an invalid mode value (e.g.,
>>"savebefore:oops"), it was treating it as "savebefore:no," instead of
>>skipping that tag.
>>
> Hi Bruce,
>
> We are definitely of two minds on the savebefore flags. Though the flags
> are applied by SciTE before a job executes, I feel that they are a
> component of the job system. Consider that the filter flag and group undo
> are used by SciTE after a job has run, it is arguable that they too should
> be removed. Since all of these flags are configured by the user with the
> command.mode property or some equivalent, I see no reason to decode and
> manipulate them separately.
>
> The use of the enum within your DecodeCommandMode() example is a better
> design that what I wrote. I will implement this, with due credit
> indicated. Thank you.
>
> April
>
> --
> I am willing to make the mistakes if someone else is willing to learn from
> them.
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
