Tim Starling wrote:
William Allen Simpson wrote:
Conrad Dunkerson wrote:
When Tim says "trial", how is the testing coordinated? Shouldn't it be
tried on a few not too prominent places, rather than fix every qif now?
Where should I be looking for posts coordinating this?
The main reason I'm calling it a trial is to avoid appearing to have made a
unilateral decision to
enable it permanently. The critics of this concept now have one final chance to turn
community
opinion against it, before it becomes ingrained. However the reception has generally been
positive.
I've received a number of private compliments on it, in addition to what can be seen
publically.
OK, here's another public compliment! Thank you!
There's also the possibility of bugs and syntax
changes. We've already had one syntax change: I
changed the whitespace handling in #if to mirror the behaviour in template parameters, to
allow for
easier conversion and neater multi-line syntax.
Yes, that's great.
... There's also a pending suggestion to allow
whitespace between the #if and the colon, and a suggestion to make #if treat
"0" as true, both of
which may well be implemented.
Please don't implement either of these.
It doesn't make sense to have whitespace between the # and the if, and no
demonstrable reason to have it before the colon.
The logic of qif was often confusing. There's only very short term
advantage to backward compatibility. Having #eval and #if work like
other languages will be easiest to document in the long term. Remember,
features aren't of much use without easy to understand documentation.
One of Gangleri's syntax suggestions sounded quite
reasonable and I may well implement it. The idea
if I understand it correctly was to treat pipe characters beyond the specified maximum
number of
arguments literally, e.g. {{#if: 1 || literal pipe: | }}.
Actually, the trailing pipe doesn't sound reasonable to me, as it only works
with "else" parameters, requiring logic to be inverted. There's a couple
of
fairly simple alternatives (standard html syntax, or the {{!}} template), and
they work in a consistent, predictable, symmetric manner. Again, ease of
documentation.