I like simplicity here, too. I don't think the minor convenience benefit
of having a default value for BCI_GetWave_Block_UI is enough to justify the
unique specification language and unique parser behavior that are required
to make that one parameter "optional".
If BCI_GetWave_Block_UI simply required when BCI_Protocol exists, just like
the other 3 parameters that already follow this rule, then things are
simpler.
That being said, I have no strenuous objection to the current version.
Thanks,
Curtis
On Tue, Oct 4, 2016 at 4:28 PM, Bob Miller <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
I generally like simplicity. Especially if the time spent understanding
the complexity offsets any hassle saved by the exceptions the complexity
affords.
But in this case it isn't really my battle. If its your front yard that is
being overrun by free-range cows you might want a more precise (and
complex) fenceline.
Regards,
Bob
On Tue, Oct 4, 2016 at 2:14 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:
All,
Per the discussion 10/4/16, I have revised the draft so that
BCI_GetWave_Block_UI
is illegal if BCI_Protocol is missing.
Curtis makes a point separately that we could just have a rule - All
BCI_*
parameters
or none and no defaults for a cleaner and simpler rule.
I could make the change, if people prefer this.
Bob
--
Bob Ross
Teraspeed Labs
http://www.teraspeedlabs.com
bob@xxxxxxxxxxxxxxxxx
Direct: 503-246-8048
Office: 971-279-5325
