Re: [SMARTY-DEV] Handling TRUE,FALSE,NULL,ON,OFF, etc

> > Regarding modifiers, > > {"xx"|STRTOUPPER} works (ie using a PHP function) > > whereas > > {""|DEFAULT:"YY"} doesn't. > > No, please don't advocate this. I'm not! (see below) > > Given all of this, is there really a good reason _not_ to accept > > TRUE/FALSE/NULL/ON/OFF etc? The performance impact is negligible (and only > > to the compiler). > > Is there a really good reason to accept them? My point (which you snipped) is that where we don't accept |DEFAULT we *do* accept TRUE/FALSE etc, then interpret them non-intuitively. We should, perhaps, insist on ="string" or =token, and not interpret incorrect tokens at all (ie error them) (there'd be big BC issues here, though). Would it be right for {"xx"|strtoupper} to generate "XX" and {"xx"|STRTOUPPER} to generate "STRTOUPPER"? Of-course not. Either "XX" or an error is fine, and I'd have no preference in a start-from-scratch project, or BC in an existing one. To accept (without error) TRUE and interpret it differently from true is counter-intuitive. I am sure that you would not advocate dropping support for TRUE from PHP and treating it as string "TRUE". (Generate a warning for a few versions then drop it from the language and error on it - fine.) Furthermore, the Smarty handling of null/NULL is completely wrong on the basis of case sensitivity, given that PHP consistently refers to it as NULL (even if it accepts null). Personally, while I think case sensitivity is a Good Thing in a programming language (eg PHP) I'm not sure it is relevant in a templating language (Smarty) - but would not argue against it. But surely we should either error on TRUE/FALSE/null if they are wrong, or interpret them intuitively otherwise. I cannot see an argument for interpreting them as they are currently interpretted. -- Mark Rogers, More Solutions Ltd