Re^3: RFC: Verify Interpreter and Language

The thing is, your example on location and associated ZIP code syntax, is one example of why a database lookup could be a good idea in a data verification language. Do you really wish to pile rule upon rule, in "code", for a single association, location<->ZIP? It seems to me like a table holding those associations would be a better idea.

Comment on Re^3: RFC: Verify Interpreter and Language

Replies are listed 'Best First'.
Re^4: RFC: Verify Interpreter and Language by exussum0 (Vicar) on Feb 10, 2006 at 16:42 UTC
I don't have a good answer for this. So bear with me. Maybe the salesperson example is bad, because of the context. I.e. a valid node id is numeric, where is a usable one is somewhere below this node number at creation time, something higher in the future. I probably shouldn't have specific data checking that is DB related built in. Btw, in the US, zipcodes are all 5 digit,then and extra 4. 00000-0000 is valid in syntax,but not in the context of being available, or usable. Just as the name xxxxxxyyyyy isvalid in most countries that use the alphabet, but you can't pronounce it. Thoughts?	[reply]

Replies are listed 'Best First'.

Re^4: RFC: Verify Interpreter and Language
by exussum0 (Vicar) on Feb 10, 2006 at 16:42 UTC

I probably shouldn't have specific data checking that is DB related built in.

Btw, in the US, zipcodes are all 5 digit,then and extra 4. 00000-0000 is valid in syntax,but not in the context of being available, or usable. Just as the name xxxxxxyyyyy isvalid in most countries that use the alphabet, but you can't pronounce it.

Thoughts?

[reply]