"Truthiness" and "Falsiness"

[pvande]

Generally speaking, there is little to no consistency between languages in the truthiness (or lack thereof) of any given value. Consequently, the fundamental description of the section tag (and its inverse) -- namely, that it's rendered when the named value is truthy (and falsey, respectively) -- is difficult to test in this specification.

The following options are available:

• Introduce two new YAML tags, !truthy and !falsey. Implementors of the spec are expected to intercept these and replace them with a non-boolean truthy or falsey value in the implementation language.

  data:
  truthy: !truthy {}
  falsey: !falsey {}

  • Pro: This provides some testing around the concept of truthiness.
  • Pro: This forces awareness of the truthiness portion of the spec.
  • Pro: This does not require any language-specific code in the core spec.
  • Con: This does not provide full coverage of all truthy / falsey values.
  • Con: This requires two additional YAML tags.
  • Con: This forces all implementors to handle these YAML tags.
    • The only other use of custom YAML tags is isolated in the optional Lambdas module.
  • Con: Non-YAML versions of the spec handle YAML tags less elegantly.

• Utilize the existing YAML tag, !code, to provide a set of language-specific truthy and falsey values.

  data:
  truthy: !code
  ruby: '[ {value: ""}, {value: 0}, {value: Object.new} ]'
  javascript: '[ {value: "non-empty"}, {value: 1}, {value: {}} ]'
  falsey: !code
  ruby: '[ {value: nil} ]'
  javascript: '[ {value: ""}, {value: 0}, {value: undefined}, {value: null} ]'

  • Pro: This provides discreet values to test with.
  • Pro: This does not require the definition of any additional YAML tags (for those already implementing the Lambda spec).
  • Pro: This can provide reasonably complete coverage of all truthy / falsey values.
  • Con: The concept of truthiness is not inherently communicated (it may appear that these values have been arbitrarily chosen).
  • Con: This forces all implementors to handle the !code YAML tag.
  • Con: This introduces language-specific code to the core spec.
  • Con: The language-specific code being added exists only for its resultant value, not for its behavior.
  • Con: This subjects the core spec to additional churn, as each new implementation language requires modifications.
  • Con: Non-YAML versions of the spec handle YAML tags less elegantly.

• Handle the concepts of truthiness and falsiness abstractly, using a pair of values that are generally recognized as truthy / falsey.

  data:
  truthy: "non-empty"
  falsey: null

  • Pro: This provides some testing around the concept of truthiness.
  • Pro: This does not require any language-specific code in the core spec.
  • Pro: This does not require any YAML tags.
  • Pro: This solution requires no additional work by the implementor.
  • Con: This does not provide full coverage of all truthy / falsey values.
  • Con: The concept of truthiness is not inherently communicated (it may appear that these values have been arbitrarily chosen).
  • Con: The chosen values carry no guarantee as to truthiness / falsiness in every implementation language.
  • Con: The possibility exists that no such pair of values exists globally.
  • Con: Working around these values in languages where either of these values behaves unexpectedly is ambiguous to the implementor.

• Provide better documentation of Mustache as a whole, including guidelines for implementors (specifically calling out, among other things, truthiness and falsiness). Responsibility for proving conformance falls to the implementation's users and to the Mustache community at large.

  • Pro: This is not exclusive with the other options.
  • Pro: This represents a significant community improvement.
  • Pro: This is completely language-agnostic.
  • Pro: The solution requires no additional work by the implementor.
  • Con: This does not provide any concrete testing.
    • As such, failures are not immediately obvious, and may lay dormant for some time.

[josh]

agibralter's example is actually pretty clear: https://gist.github.com/820519

[pvande]

Updated the ticket with additional options, including one inspired by agibralter's example.

[josh]

Improving documentation can be done regardless. A simple statement like "A value should be considered empty if it is an empty structure or it evaluates to false according to the host language." Thinking empty or emptiness maybe a better term than truthy because it includes empty arrays and hashes.

"Utilize the existing YAML tag, !code, to provide a set of language-specific truthy and falsey values." - seems like the clearest way to specify this. It might be good to do this in an optional section so the core spec can be free of !code sections. I think we can come up with a definitive list of values for ruby, perl, js, php, and python.

[pvande]

Improvements to documentation can be done independently of any other solution; it's actually one of the called-out benefits. I hesitate to associate too closely with the concept of "emptiness", however, as there is very inconsistent correlation between truthiness and emptiness.

If we were to use the !code tag, which certainly is the most explicit option, it would need to be in the core spec; optional modules are for functionality that may be too difficult to implement cross-platform or otherwise doesn't need to be implemented for compliance. I'm hesitant to introduce a third type of module ("not optional, but you don't have to pass this"?) or to redefine 'optional', since both actions seem to significantly complicate and muddy the spec.

The current list of Mustache implementations also extends far beyond those five languages, many of which in languages that will be ill-suited to handling the !code construct dynamically.

[pvande]

For the time being, this will be enshrined in the documentation for the Section and Inverted Section tags. We will investigate more explicit options if and when we have a demonstrable problem.