On 8/11/2016 10:19 PM, Lester Caine wrote: > No ... add more than just validation rules. Include facilities such as > escape rules, display rules and variable specific material such as error > messages. > > Just how the rules are enforced needs to be flexible and such things as > 'required' will vary how the results are interpreted. I don't see that a > dynamic scripting language is improved by 'language-level enforcement' > when the bulk of the data IS flexible. It is the flexibility to include > or exclude checks as required and while a sub-set of code may work > better with a fixed set of rules defined at 'design time', just as much > code will consist of elements of the data set that will be optional or > variable. 'is_valid' on an object with a large set of variables is an > equally valid check and if each variable has the autonomy to return it's > state depending on other variables, then only the currently 'required' > variables need to be set and validated. > > I AM interested in tracking the state of each variable but the validity > of it's state may depend on the specific state of other elements and a > failure to set a variable depends on the particular workflow of the > whole data set. So creating a workflow that allows different paths based > on the results of validation is a lot more flexible than simply calling > 'validate' on a static array of variables? > > But to keep the 'exception' camp happy, there is no reason that the > 'strict' mode can't return exceptions while the 'weak' mode allows the > error to simply select an alternate path through the code. >
What you are describing are classes. You can achieve all of that with them. You are completely right btw. that exceptions should not be used during validation and for flow control. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
