Re: 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

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php