Why "Lambdas used for inverted sections should be considered truthy"? #158
Replies: 12 comments
-
No. There is a subtle difference in the treatment of context methods depending on whether the lambdas extension is implemented. Suppose that we have the following template (with a non-inverted section, but bear with me for a moment): {{#meaning}}42{{/meaning}} and that the context is the following JavaScript object: {
meaning: function(sectionText) {
return '<b>' + sectionText + '</b>';
}
} then a Mustache engine that doesn't implement the lambdas extension will render (The distinguishing feature of the lambdas extension is not that lambdas/functions/methods are invoked in the first place. The basic interpolation, sections and inverted specs already require that they are invoked and that their return values are used. The real distinguishing feature is that lambdas/functions/methods gain additional influence over what is rendered. I didn't realize this myself until I read the specs a few times.) Inverted sections obviously need to behave opposite to regular sections. According to the lambdas extension, a section will invoke a context method in order to establish the inner template text to be rendered. So an inverted section will NOT invoke a context method, let alone render whatever template text it might return. |
Beta Was this translation helpful? Give feedback.
-
where? there is no lambdas in
if it doesn't support lambdas, sure, it will not.. same logic may be applied to normal section (why not?), there is no point in compatibility with lambda and non-lambda engines by the means of making
because still, it will give different results (
and will be variables first compatible..
is more appropriate (with lambdas).. maybe i miss something.. but it appears unlikely.. |
Beta Was this translation helpful? Give feedback.
-
You are right to point out that there is no test for lambdas in the sections spec. However, the overview of the sections spec does prescribe that lambdas must be invoked and that their return values must be used for name resolution: Lines 18 to 22 in bb63070 You find exactly the same prescription in the inverted spec: Lines 19 to 23 in bb63070 As I wrote before, that is already the specified behavior without even including the lambdas extension. It is important to realize that this takes place as a step during name resolution. Name resolution must be fully complete before the engine even starts to determine what will be rendered. So in all cases (variables, sections and inverted sections, whether the lambdas extension is implemented or not), taking inspiration from your notation, the following is what happens during name resolution:
Without the lambdas extension, section rendering proceeds as follows:
The inverted section applies the same conditions, except that it only renders the original section template if With the lambdas extension, there is an additional condition before section rendering starts:
You find that prescribed over here: Lines 10 to 13 in bb63070 While it's left somewhat implicit, I think the appropriate opposite behavior for inverted section is as follows:
and as far as I can tell, the particular test that you're asking about agrees with this interpretation. Note that since "once" becomes "zero times", the inverted section effectively never renders a lambda, so the Mustache engine can optimize the lambda invocation away. |
Beta Was this translation helpful? Give feedback.
-
now i get it, i missed the object.method call.. let me examine the logic.. will return to it today.. |
Beta Was this translation helpful? Give feedback.
-
Ooke, let's clarify some wording..
Take a look at this JavaScript object (last lambdas test):
when the name Same goes with JavaScript arrays, they are considered objects. Which is false for PHP. My opinion is that the name resolution should be separated from the knowledge of variable/section/inverted. This way, no object.method call will be made, only traversal. When the object.method is found as the last name (for example Why not call?It was already prescribed to call them.
vs falsy check first:
im really lost with this spec :) |
Beta Was this translation helpful? Give feedback.
-
Please excuse me for quote-sniping you a little.
Depending on the language, a lambda might be a closure, in which case it might actually be bound to a particular object/context. I've been carefully avoiding the word "lambda" alone when referring to callable functions, because of the wild variety of possible interpretations. With the Mustache spec in mind, "lambda" should be mostly thought of as a feature of the Mustache templating language, rather than a feature of a programming language. As you probably already realized, a lambda in Mustache will be a method in the underlying programming language most of the time.
So far, I think I understand what you mean, ...
but here, I'm losing you. Do you mean that there is a conflict with what I've written so far? I'm not seeing it.
I fail to see how this is relevant.
In that case, I think the spec agrees with you. Methods earlier in the chain still need to be invoked at this stage, though. In your example above, if
Here is the full algorithm that the spec prescribes (as far as sections and inverted sections are concerned):
|
Beta Was this translation helpful? Give feedback.
-
according to your code, when take a look at my interpretation: un-commenting the block (after the falsy check) will comply with the lambda spec (this issue), but, it means that functionality will be removed, not added. as i understand, the main reason why "lambdas" was made - is to replace/substitute section's content, which inverted section can't do by means of common sense, what they can, is to specify a flag (as a call result), with this test, the flag is not respected. so the question "why" is about the flag being needed or not. |
Beta Was this translation helpful? Give feedback.
-
True. As I wrote before, there is a lot that can be optimized away. My own implementation does that, too. I was just representing the un-optimized algorithm as it is described in the spec.
I can't really comment on your implementation without giving it a lot of study first, but I will take your word for it.
I wasn't around when the spec was written. With that out of the way, there are lots of subtle variations possible when defining the semantics for a formal language (as you illustrated with your comments). The authors need to take care to pick a combination of variations that is (a) useful, (b) practically implementable and (c) consistent. The alternative that you are suggesting, where inverted sections are basically exempt from the lambdas extension, is arguably useful. As you wrote, doing so would allow inverted sections to make a yes/no rendering decision based on what the named function returns. However, that wouldn't be consistent. Consider the following example:
First consider the case that Next, consider the case that Finally, consider the case that The algorithm in the spec avoids the contradictions that I described above. If |
Beta Was this translation helpful? Give feedback.
-
what is wrong/contradicts here? |
Beta Was this translation helpful? Give feedback.
-
This is contradictory. In the first case, you are interpreting the returned string as a new template. In the second case, you are effectively interpreting the string as a boolean. In order for these two conditions to be consistent with each other, you'd either have to render |
Beta Was this translation helpful? Give feedback.
-
yes, because the nature of
better? means that template |
Beta Was this translation helpful? Give feedback.
-
These two cases are no longer contradictory, but now case 1 is contradictory with both case 2 (
Those templates are not equivalent; they still give different results if |
Beta Was this translation helpful? Give feedback.
-
shouldn't it be (for inverted)
plus (maybe)
Beta Was this translation helpful? Give feedback.
All reactions