Fallthrough sections #178
Replies: 2 comments 11 replies
-
yes, switch (value) {
case 1:
// ...
// fallthrough to 2
case 2:
// ...
break;// no fallthrough
default:
// ...
break;
}an absense of the next Q to the public and implementers is whether stack pushing needed: with data [
"animal" => "mouse"
]in my implementation currently becomes: do you agree with that behavior/logic? EDIT: oke, i forgot that fallthrough is actually utilized by using this extended syntax: +EDIT switch (number) {
case 1:
case 2:
case 3:
case 4.5:
// ...
break;
case 1:
// ...
break;
default:
// ... non zero
break;
inverted_default:
// ... zero
break;
} |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for clarifying. 👍 I'm not fond of having a literal after the I now realize that in the opening post, I let go of the restriction that all clauses should be about the same variable. With hindsight, that is perhaps a bit too liberal. On the other hand, not having that restriction would play nice with the pattern I've had in mind for the "trailing comma + 1" problem. That is, if I have a list, say Fallthrough sections without a "same variable" rule would allow me to write something like this instead (though I still don't like the double sigil notation): Regarding switch cases without a switch(number) {
case 1:
case 2:
case 3:
case 4.5:
write('number is either 1 or 2 or 3 or 4.5');
case 0:
break;
default:
write('not zero');
}This also illustrates a counter-intuitive side effect of the way you implemented the feature. Since you cannot start more specific than zero or non-zero, non-inverted section switches start with the default case instead of ending with it. I think that, given a choice to restrict all cases to the same variable, you did the best possible, but I don't like it for the above reasons. I would also prefer to reserve a notation like |
Beta Was this translation helpful? Give feedback.
-
such a syntax will not work for a single value in the list plus it would bring a mess into codebase and reduce template readability, the correct one is: i intentionally put the purpose of a
well, it's not a variable, it is a value which might be the result of a lambda invokation. variable switch (value) {
default:
break;
case 1:
break;
}only the order of conditional sections is taken into account.
if you want to standardize some syntax you need more examples that showcase its benefits. |
Beta Was this translation helpful? Give feedback.
-
|
Alright. I showed one realistic example, i.e., the trailing comma +1 scenario. How about you show a realistic scenario where your I mean, I understand that it mimics |
Beta Was this translation helpful? Give feedback.
-
any example that has more that two render variants of the same entity. for example a it can be:
so the analyzer creates render example github discussion is putting quotation at the top, which is wrong, but i wont fix it |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. By reducing the use case to its essence, you made it more convincing for me. Current Mustache can do value-based branching using dynamic partials. I will readily admit that the following solution is not ideal, but it works: Playground savestate (render the As I already acknowledged, this solution is not ideal. We need to have external templates with tiny integer names. The external templates themselves are also tiny. Despite that, the above solution also has two advantages over your syntax: it does not require writing literal values inside the template (see footnote), and it is easier to add more log levels later, or to change the labels of some of the log levels, because there is a single source of truth about the possible log levels. The tiny external templates could be replaced by tiny internal templates using #162: Catering to situations where the subtemplates are more than just a single word, we could alternatively address the tiny integer names using #153, so we could externalize the subtemplates with sensible names: {
LEVEL_MAP: ['log_info', 'log_warn', 'log_error'],
loglevel: function(level) {
return LEVEL_MAP[level];
}
}Both approaches could also be combined: In the general case, where the templates for the individual log levels might be complex, I think that a solution that combines dynamic partials with nested templates and/or filters is superior to what you are proposing. In this specific example, they are just single words, so I would probably return that word directly from a filter and skip the partial altogether: {
LEVEL_MAP: ['INFO', 'WARNING, 'ERROR'],
loglevel: function(level) {
return LEVEL_MAP[level];
}
}All this being said, you are right that at least one new feature is needed. I would favor both #162 and #153 over your Footnote: literal values inside templates may seem innocent if they are just numbers or strings. However, literal values aren't always numbers or strings; they could also be entire datastructures. Having syntax for that is very far beyond the scope of Mustache, as far as I'm concerned. |
Beta Was this translation helpful? Give feedback.
-
external templates? you mean that it is required to type a number as a filename? that would be 3 sources of truth (3 files) instead of one template. beside that, what if you need more branching on numeric values? like
yes, that is better, but still prone to name collision.
here you realize the name collision problem and successfully workaround it.
one more step and mustache engine will be out of service :] to re-establish mustache authority, my implementation of lambdas comes into help: rendering will depend on
internal templates (#162) doesnt need another invention, they are naturally appear inside sections (what i call blocks): that's the case where less is more. less sigils, less logic, less mental load - more templating language |
Beta Was this translation helpful? Give feedback.
-
Right, that is why I acknowledged that the current standard solution is not ideal. I think you are right that at least some new feature is needed in the Mustache language, in order to handle your use case in a satisfying way.
The difference is that
Just before that, I showed you Now I'm adding
That example was not a "renderer function", but an extremely simple function that maps a number to a word. Contrary to the solution you showed before, the template author would not need to repeat herself if she needed to make the same mapping in more than one place. Which brings me to your new example, where you introduce lambda arguments and in-template context modification in order to solve that:
Here I really disagree with you. So far, Mustache has made a conscious choice to leave some of the functionality in the host programming language, so that the template language can stay lean and mean. That, by itself, is a separation of concerns: let the host language do data processing and let the template language do the presentation. You are basically proposing to turn Mustache itself into a programming language, which amounts to removing that separation of concerns.
Sections do not replace internal templates, in the same way that loops do not replace functions. |
Beta Was this translation helpful? Give feedback.
-
"If it walks like a duck and it quacks like a duck, then it must be a duck".
i ignored the syntax of a sloppy (error prone) variant because the correctness is what comes before clarity.
lets compare the clarity, your example adds:
mine (the
i didnt say it was "renderer", i said developer will move to writing renderer functions where your
the concern is if i wanted to break it, i wouldnt use
nah, my version effectively keeps
sections do not, but section's content is an internal template by nature. it adds a confusion. |
Beta Was this translation helpful? Give feedback.
-
I will admit that your syntax is simpler. However, it only addresses this use case and there is a large overlap with dynamic partials, which are already standard. While my syntax is perhaps not as clean, it relies on features that have wider applications. Regarding Besides that, |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
@determin1st has been championing a variant of this idea in several other discussions. For reference, I will link two posts where he described it: #157 (comment) and before that, #135 (comment). The present discussion is dedicated to any feature that would give Mustache a concise notation for if/elif/elif.../else like fallthrough cases.
The long time status quo in Mustache is that you need to repeat a condition in order to do an if/else:
If you lean very much to the pragmatist side (#163), situations like the above make it tempting to introduce an
elsekeyword into the language:I feel this would be very un-Mustachy.
{{else}}should just be an interpolations tag that looks for anelsekey in the context.It gets a lot better already if you use a
|sigil instead of anelsekeyword:In combination with an inverted section, this notation also lets you do something that currently cannot be done without data preprocessing (see option 9 in #157):
It's just that the use case is a bit narrow. However, if
|is a sigil, that means there could potentially be some kind of payload after it. That would make it possible to extend this syntax to a Mustache equivalent of a switch statement with multiple fallthrough cases (note that this relies on #175 to avoid a confusing closing tag):We save ourselves three tags per case in this way. If we compare this to status quo Mustache, the saved effort is quite substantial even for just three cases:
I suspect this is the idea that @determin1st originally came up with and that eventually evolved into the feature he implemented in sm-mustache (see references above). The idea that he actually implemented is more intricate than what I illustrated here; it includes equality comparisons to literal values and multiple fallthrough cases within a single
|tag. I personally think those intricacies deviate too much from Mustache's core principles, so I defer to @determin1st if he feels like discussing them.Continuing from the above example, I see two problems. Firstly, it makes sense that
{{|cases can be chained both after{{#and after{{^. It also makes sense that conditions in a{{|can be written in the same way as in a{{#or a{{^, so with dotted names that resolve to the context. However, this means that it is ambiguous whether the{{|itself is a positive (#) or a negative (^) condition. It is easy to imagine situations where one might want to chain a mixture of positive and negative cases, so it would be too restrictive to always use the sign of the{{#or{{^that opened the chain.Secondly, the
|could be confused for the|operator in filter syntax (#153), an idea I'm more fond of than fallthrough sections.The first solution that I thought of, but which does not work, is to simply start a new
{{#or{{^without closing the previous one. This does not work, because it is impossible for a parser to distinguish from nested sections with omitted closing tags. It also means that the|sigil is still required, just to mark the default case:Another option, which would work but which I dislike, would be to use double sigils:
Or yet another option that I would dislike: add a second sigil specifically for negative fallthrough cases, for example
{{\.I don't see an acceptable way yet in which fallthrough cases could be implemented. Despite that, the idea has grown on me, so I hope for another round of inspiration!
Beta Was this translation helpful? Give feedback.
All reactions