I understand that, but why bring the handling of invalid macros down to the lowest common denominator? If the processing is to be changed why not take the opportunity to change it so that macros both inside and outside strings will generate an error if they are mistyped?
Consider this bit of code:
Code:
$sMailAddress="helpdesk@service.acme.com"
This is a coding error. If the "@" symbol is intended to be present in the string it should be doubled up "helpdesk@@service.acme.com" - that is the KiXtart syntax.
If the parser is changed to ignore the error then this code will work. But what happens in KiXtart release 4.xx when Ruud introduces the new @SERVICE macro to indicate when a script is running as a service? Oops. It would be better if the programmer had been notified the very first time he tested the script that the string contained an invalid macro. He would have doubled up the "@" and there would be no chance of a namespace clash in the future.
