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.