how to render booleans?

[determin1st]

for example,
template:

user active: {{user.active}}

data:

['user' => ['active' => true]]

output:

user active: 

with the instance option:

'booleans' => ['no','yes']

output:

user active: yes

other variants?

[jgonggrijp]

Wontache renders user active: true. Wontache has no option that controls how booleans are rendered, truth always renders as true and falsehood always as false, as those are the builtin serializations in JavaScript.

As far as I can tell, the spec does not prescribe exactly what to do with booleans, other than that any data should be coerced to string. That might be on purpose, in order to allow implementations some freedom and ease.

[determin1st]

python coerces to True
php coerces to 1
javascript coerces to true

i propose mustache coerce both to empty string by default. that's a basic level of functionality which, imo, should be determined.
also, should the stack expansion happen with booleans:

{{#non-zero-integer-here}}
  {{#boolean-here}}
    integer or boolean - {{.}}?
  {{/}}  
{{/}}

[jgonggrijp]

i propose mustache coerce both to empty string by default. that's a basic level of functionality which, imo, should be determined.

Coercing to the empty string rather seems like non functionality to me. In that case you cannot even see the difference between truth and falsehood. An implementation-specific pair of constrasting values (True vs False, 1 vs 0, yes vs no, etcetera) seems much more useful.

also, should the stack expansion happen with booleans:

{{#non-zero-integer-here}}
  {{#boolean-here}}
    integer or boolean - {{.}}?
  {{/}}  
{{/}}

Yes, this is already specified. The implicit iterator must take on the value of boolean-here:

spec/specs/sections.yml

Lines 30 to 36 in 83b221a

	If the data is not of a list type, it is coerced into a list as follows: if
	the data is truthy (e.g. `!!data == true`), use a single-element list
	containing the data, otherwise use an empty list.
	For each element in the data list, the element MUST be pushed onto the
	context stack, the section MUST be rendered, and the element MUST be popped
	off the context stack.

spec/specs/sections.yml

Lines 71 to 78 in 83b221a

	- name: Variable test
	desc: |
	Non-false sections have their value at the top of context,
	accessible as {{.}} or through the parent context. This gives
	a simple way to display content conditionally if a variable exists.
	data: { foo: "bar" }
	template: '"{{#foo}}{{.}} is {{foo}}{{/foo}}"'
	expected: '"bar is bar"'

Booleans are not always explicitly mentioned in the spec, because not every programming language treats them as a separate type. PHP is also a bit in a grey zone in that regard. Regardless, I think it would be most consistent for booleans to be treated in the same way as all other types:

spec/specs/sections.yml

Lines 182 to 237 in 83b221a

	# Implicit Iterators
	- name: Implicit Iterator - String
	desc: Implicit iterators should directly interpolate strings.
	data:
	list: [ 'a', 'b', 'c', 'd', 'e' ]
	template: '"{{#list}}({{.}}){{/list}}"'
	expected: '"(a)(b)(c)(d)(e)"'
	- name: Implicit Iterator - Integer
	desc: Implicit iterators should cast integers to strings and interpolate.
	data:
	list: [ 1, 2, 3, 4, 5 ]
	template: '"{{#list}}({{.}}){{/list}}"'
	expected: '"(1)(2)(3)(4)(5)"'
	- name: Implicit Iterator - Decimal
	desc: Implicit iterators should cast decimals to strings and interpolate.
	data:
	list: [ 1.10, 2.20, 3.30, 4.40, 5.50 ]
	template: '"{{#list}}({{.}}){{/list}}"'
	expected: '"(1.1)(2.2)(3.3)(4.4)(5.5)"'
	- name: Implicit Iterator - Array
	desc: Implicit iterators should allow iterating over nested arrays.
	data:
	list: [ [1, 2, 3], ['a', 'b', 'c'] ]
	template: '"{{#list}}({{#.}}{{.}}{{/.}}){{/list}}"'
	expected: '"(123)(abc)"'
	- name: Implicit Iterator - HTML Escaping
	desc: Implicit iterators with basic interpolation should be HTML escaped.
	data:
	list: [ '&', '"', '<', '>' ]
	template: '"{{#list}}({{.}}){{/list}}"'
	expected: '"(&amp;)(&quot;)(&lt;)(&gt;)"'
	- name: Implicit Iterator - Triple mustache
	desc: Implicit iterators in triple mustache should interpolate without HTML escaping.
	data:
	list: [ '&', '"', '<', '>' ]
	template: '"{{#list}}({{{.}}}){{/list}}"'
	expected: '"(&)(")(<)(>)"'
	- name: Implicit Iterator - Ampersand
	desc: Implicit iterators in an Ampersand tag should interpolate without HTML escaping.
	data:
	list: [ '&', '"', '<', '>' ]
	template: '"{{#list}}({{&.}}){{/list}}"'
	expected: '"(&)(")(<)(>)"'
	- name: Implicit Iterator - Root-level
	desc: Implicit iterators should work on root-level lists.
	data: [ { value: 'a' }, { value: 'b' } ]
	template: '"{{#.}}({{value}}){{/.}}"'
	expected: '"(a)(b)"'

Playground savestate that demonstrates Wontache's implementation:

{"data":{"text":"{\n    \"non-zero-integer-here\": 1,\n    \"boolean-here\": true\n}"},"templates":[{"name":"","text":"{{#non-zero-integer-here}}\n  {{#boolean-here}}\n    integer or boolean - {{.}}?\n  {{/boolean-here}}  \n{{/non-zero-integer-here}}"}]}

[determin1st]

oke, regardless of what was written previously, try to find any advantages of the first VS the second section:

{{#boolean-here}}
  result is {{.}}
{{/}}

{{#boolean-here}}
  result is true
{{/}}

i cant find any - only disadvantages i see - one is performance, the other is backpedal obstruction:

{{#users-array}}
  {{#.active}}
    user {{..name}} is active
  {{/}}
{{/}}

{{#users-array}}
  {{#.active}}
    user {{.name}} is active
  {{/}}
{{/}}

dont think that's the best example, but it shows that true values will start to fill the stack without a good reason so the absolute paths will become cumbersome in higher levels of nesting

it's not the PHP which is in gray zone, its all three i mentioned, they all have boolean type. if the spec doesnt specify how boolean reanders, then there will be no standard among implementations, again, in such a primitive render scenario.

[jgonggrijp]

{{#boolean-here}}
  result is {{.}}
{{/}}

{{#boolean-here}}
  result is true
{{/}}

I agree the second template is better than the first. It is faster and more portable. However, that is true regardless of whether boolean-here is pushed on the stack or not.

(...) backpedal obstruction:

(...)

(...) true values will start to fill the stack without a good reason so the absolute paths will become cumbersome in higher levels of nesting

While I agree that true values on the stack are useless, we would pay a dear price for skipping them. Consider a variable that is sometimes boolean and sometimes a number or string. In the following example, user.authenticated may be true, false or 'pending':

{{#user}}
    {{#authenticated}}
        Welcome, {{..name}}
    {{/authenticated}}
{{/user}}

If strings are pushed on the stack but booleans are not, then the above template will not work reliably. Consistency is important.

Returning to your other question regarding the way booleans are coerced to string, and to your first example:

user active: {{user.active}}

If all booleans coerce to the empty string as you proposed, then the above template is useless. If booleans coerce to an implementation-specific, non-empty string instead, then at least the observer of the template output will be able to distinguish between true and false states.

Regardless, the following would be more portable, but less performant (even if you were to introduce {{|}}):

user active: {{#user.active}}yes{{/user.active}}{{^user.active}}no{{/user.active}}

[determin1st]

While I agree that true values on the stack are useless, we would pay a dear price for skipping them. Consider a variable that is sometimes boolean and sometimes a number or string. In the following example, user.authenticated may be true, false or 'pending':

{{#user}}
    {{#authenticated}}
        Welcome, {{..name}}
    {{/authenticated}}
{{/user}}

If strings are pushed on the stack but booleans are not, then the above template will not work reliably. Consistency is important.

that's not consistency, let user.authenticated be true, false, 'pending' or ['yes',123] - that is consistency... not. different types - mine will fail terribly upon rendering pre-cached (aka pre-compiled) template stuffed with different types. beside it breaks the data for template principle.

the consistency here goes after the ^ block behavior - it doesnt push false values to the stack, meaning the # block should not push true values.

If all booleans coerce to the empty string as you proposed, then the above template is useless. If booleans coerce to an implementation-specific, non-empty string instead, then at least the observer of the template output will be able to distinguish between true and false states.

template will be useless but exception wont be thrown as currently mine does for object and array types. PHP coerces false to the empty string btw, so i thought that empty string would be a neutral render.

non-mustache implementation-specific means implicit. my proposition is to make it explicit - choose something, empty strings or false,true.

[jgonggrijp]

{{^}} never pushes the test value to the stack, so at least it is consistent with itself. {{#}} always pushes its value to the stack. Changing that to make an exception for booleans would make it less consistent with itself.

I lied a little bit here; if the {{#}} value is a callable that returns a string and the lambdas extension is implemented, then the return string will override the template instead of being pushed on the stack. However, that does not change my argument; adding another exception for booleans will make the situation worse, not better.

As for rendering booleans with fixed strings, such as true and false, I see one advantage and one disadvantage.

Advantage: users can rely on boolean interpolation rendering the same across implementations. This is somewhat offset by the fact that users will often want a different way to render booleans, so they will end up doing if/else sections anyway.

Disadvantage: many implementations, especially in dynamically typed programming languages, can currently just use the built-in string coercion without needing to do much type detection in advance. For example, non-extension-lambda value interpolation is currently a oneliner in Wontache:

https://gitlab.com/jgonggrijp/wontache/-/blob/afbc9c23b0e8e489b8ecc0bf85c8121ee7ce8fcc/mustache/mustache.coffee#L189

If we start requiring particular serializations for particular values, these implementations will have to start adding code branches for various types. Suppose that we were to settle on yes and no for booleans, then Wontache's code size would have to grow by about 3 lines. That may not seem like mucht, but it is a lot for an implementation of less than 500 lines which is also trying to stay as small as possible. Since Wontache targets JavaScript, end users often have to download it to their device and they may have to do so over a flaky EDGE connection, so size really matters.

I'm not saying that Wontache must never grow, but if it grows, it better be for a reason that gives users something valuable in return. I honestly feel that the tradeoff is not very good in this case.

Similar size constraints might also apply to implementations for other languages, for example if targeting microcontrollers or mobile apps. Hence, even if we were to choose specifically true and false, which would remove the need for branching in Wontache, there might still be some other implementation facing a bad tradeoff.

[determin1st]

# has different behaviors for different types and even different behaviors for the same types - empty string, empty array, zero number - are examples when the value is not pushed to the stack, non-empty arrays are iterated, mine also distinguishes iterable+countable objects from the other objects, lambdas may do content substitution. so if you want to push useless trues to the stack - that will be your problem in the future (which relates to the stack addressing)

size argument is kind of 10-20 years old :] there's more useful ideas to implement with mustaches than to argue about boolean rendering, ill take no,yes then

[jgonggrijp]

# has different behaviors for different types and even different behaviors for the same types - empty string, empty array, zero number - are examples when the value is not pushed to the stack, non-empty arrays are iterated,

All the behaviors you describe fit in a single algorithm:

1. If the value is already an array, skip to step 4.
2. Create an empty array.
3. If the value is truthy, add it to the array.
4. Repeat the section for each element of the array, pushing the element to the stack.

This is roughly how all Mustache engines currently implement sections. It is also what users expect. Omitting a boolean truth value from the stack does not fit in this algorithm.

size argument is kind of 10-20 years old :]

I fail to see what the age of the argument has to do with it. Mustache itself is nearly 15 years old; do you think Mustache is no longer relevant?

there's more useful ideas to implement with mustaches than to argue about boolean rendering

At least we can agree about this!

[determin1st]

# has different behaviors for different types and even different behaviors for the same types - empty string, empty array, zero number - are examples when the value is not pushed to the stack, non-empty arrays are iterated,

All the behaviors you describe fit in a single algorithm:

1. If the value is already an array, skip to step 4.
2. Create an empty array.
3. If the value is truthy, add it to the array.
4. Repeat the section for each element of the array, pushing the element to the stack.

This is roughly how all Mustache engines currently implement sections. It is also what users expect. Omitting a boolean truth value from the stack does not fit in this algorithm.

nope, this algo is a waste, low-spec mobile phones will discharge on it and reboot. empty string wont reach the stack - falsy checks go first. to do falsy checks, type checks are mandatory:

1. resolve path to value.
2. goto 4 for non-lambda.
3. invoke lambda, when result is a string - do a content substitution and complete.
4. when value is falsy - render empty or "OR" section and complete.
5. when value is a countable container - do iteration (multiple push & renders) and complete.
6. helper value - do a single push & render

well, i noticed that the spec tests dont have falsy checks. you have to fix that for the sake of consistency, add these:

{{#number-zero}}
  never render {{.}}
{{/}}

{{#empty-string}}
  never render {{.}}
{{/}}

size argument is kind of 10-20 years old :]

I fail to see what the age of the argument has to do with it. Mustache itself is nearly 15 years old; do you think Mustache is no longer relevant?

imo, relevancy moved from the frontend to the backend.

there's more useful ideas to implement with mustaches than to argue about boolean rendering

At least we can agree about this!

thats not the agreement, agreement happens when you accept no,yes as the default