I've looked into adding #on support to #switch and I think the following needs
further consideration: how #break works in #switch with #on?
When using #switch with #case in a #list, #break finds the #switch and breaks
out of that, rather than the #list.
<#list [1,2,3] as item>
<#switch item>
<#case 2> It's 2 <#break> <!-- Breaks from #switch, not #list -->
<#default> Not 2
</#switch>
</#list>
Mixing #list with #on, what's the behavior?
1. #break is in a #switch and so it breaks from that
2. #break is in an #on and so throws an error because #on does not allow that
3. #break acts like it's used by #list and so breaks from that, rather than the
#switch
<#list [1,2,3] as item>
<#switch item>
<#on 2> It's 2 <#break> <#-- break from #switch, break from #list or
throw error? -->
<#default> Not 2
</#switch>
</#list>
P.S.
It seems that #switch currently doesn't distinguish between #break and
#continue. As a result, the following treats #continue as if it's a #break,
rather than skipping to the next item in the #list.
<#list [1,2,3] as item>
<#switch item>
<#case 2>
${item}
<#continue>
<#default>
${item}
</#switch>
After
</#list>
The output is:
1
After
2
After
3
After
Rather than:
1
After
2
---
Best regards,
Simon Hartley
On Monday, 5 February 2024 at 23:21:13 GMT, Daniel Dekany
<daniel.dek...@gmail.com> wrote:
#on is maybe better than #option... I'm not a native english speaker
though, so I'm nor entirely sure.
Someone else asked what if it's mixed with #case. I would just disallow
that.
And of course, with #on (or #option) there would be no fall though at all.
Since we have multiple values per #on, there's almost no use-case for it.
On Tue, Feb 6, 2024 at 12:11 AM Denis Bredelet <brede...@me.com.invalid>
wrote:
> Hello,
>
> Good suggestions here. I think #option works well.
>
> You could also use #switch … #on … #on …
>
> If you want to keep #case and add a modifier, I suggest break=req (the
> default, #break is required to exit the #switch) and break=opt (#break only
> required when you want to exit the #case early).
>
> Cheers
> — Denis.
>
> > On 3 Feb 2024, at 21:20, Simon Hartley <scrhart...@yahoo.co.uk.invalid>
> wrote:
> >
> > If you leave the parent directive as switch, then there would need to
> be a decision for what should happen if the user tries to mix option and
> case in the same switch, i.e. should it "just work"?
> >
> > I did remember that JSP used choose/when/otherwise, so your previous
> suggestion isn't without precedence. #option is as good as any (ahead of
> #choice and #when ???), but here are some more random words anyway: #check,
> #criterion, #test
> >
> > Your idea for multiple values per case seemed like a nice upgrade. What
> are your thoughts on "values" being expressions as I touched on in the
> Future Work section?
> >
> >
> >
> >
> >
> >> On Saturday, 3 February 2024 at 18:19:09 GMT, Daniel Dekany <
> daniel.dek...@gmail.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >> <#switch value fallthrough="explicit">
> >
> > With that it's at least clear which behavior we get, but then I guess
> it's
> > too verbose.
> >
> >> I would point out that Java switch expressions (not statements) don't
> > allow fall-through at all.
> >
> > I'm pretty confident that if we support multiple values per #case (or
> > whatever it will be called), then fall-through is just not worth the
> > trouble.
> >
> >> Java 21 Pattern Matching syntax
> >
> > That's unfortunate, as #when was high on my list. Though it's not in
> place
> > of "case" in Java, so it's maybe not that confusing if we have it in
> place
> > of #case. Anyway, how about #option then?
> >
> > <#switch contact.type>
> > <#option 'INDIVIDUAL', 'PROXY'>
> > ...
> > <#option 'ORGANIZATION'>
> > ...
> > <#default>
> > ...
> > </#switch>
> >
> >
> > On Sat, Feb 3, 2024 at 6:11 PM Simon Hartley <scrhart...@yahoo.co.uk
> .invalid>
> > wrote:
> >
> >> Cool.
> >>
> >> Just to cover all bases, what about the switch behavior remaining the
> same
> >> unless you opt-in using something like:
> >> <#switch value fallthrough="explicit">
> >> Would you still rather not add the mental overhead of such modal
> behavior?
> >> Given your reaction to Go's choice, I assume you'd rather not do that.
> >> I would point out that Java switch expressions (not statements) don't
> >> allow fall-through at all. (There is a compile error if you try to use
> the
> >> block syntax that doesn't contain a yield and without the block syntax
> then
> >> the yield is implicit.)
> >>
> >> If we went the new directive route, should it allow fall-through at all?
> >>
> >> Naming with a new directive may require care, since when clauses are
> part
> >> of Java's new Java 21 Pattern Matching syntax and so may lead to higher
> >> expectations.
> >> (see:
> >>
> https://docs.oracle.com/en/java/javase/21/language/pattern-matching-switch-expressions-and-statements.html#GUID-A5C220F6-F70A-4FE2-ADB8-3B8883A67E8A
> >> )
> >>
> >>
> >>
> >>
> >>
> >> On Saturday, 3 February 2024 at 09:44:38 GMT, Daniel Dekany <
> >> daniel.dek...@gmail.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >> I'm not against addressing the core issue, but the only practical way I
> can
> >> imagine is with different directive names.
> >>
> >> Breaking existing templates is out of the question.
> >>
> >> It can't be a configurable behavior either, because then if you just
> look
> >> at a template, you can't be sure what will actually happen. Consider
> >> answering SO questions like that, or copy-pasting template snippets from
> >> elsewhere.
> >>
> >> What Go did is just wrong, IMAO. They had to find a different name to
> avoid
> >> confusion, like choice/when, or whatever. Same goes for FM.
> >>
> >> On Fri, Feb 2, 2024 at 2:38 AM Simon Hartley <scrhart...@yahoo.co.uk
> >> .invalid>
> >> wrote:
> >>
> >>> The below is structured as a proposal, but at the moment I just want to
> >>> gather opinions and also see if this a non-starter or not. It includes
> >>> options for adopting this in version 2 or the theoretical version 3.
> >>> Putting dev effort aside for the time being, is this a reasonable thing
> >> to
> >>> address and does it align with the desired approach?
> >>>
> >>>
> >>> ## Summary ##
> >>>
> >>> Enhance the switch directive to not force fall-through behavior. Using
> >>> switch is currently clunky and the available alternatives have their
> own
> >>> compromises. It should not exist in its current form in the next major
> >>> release.
> >>>
> >>> ## History ##
> >>>
> >>> The FreeMarker switch directive mimics the Java switch statement. It
> >>> supports fall-through and this is the control flow unless break is
> >>> encountered. The manual recommends against this directive due to this
> >>> error-prone behavior. Later, the switch built-in was added which does
> not
> >>> have the concept of fall-through.
> >>>
> >>> ## Goals ##
> >>>
> >>> * Avoid unnecessary syntactic noise caused by having to use the break
> >>> directive
> >>>
> >>> * Avoid accidental fall-through by making it explicit when needed
> >>>
> >>> ## Motivation ##
> >>>
> >>> * Avoid the potential for repetition due to elseif as a replacement
> >>>
> >>> * Offer increased syntactic clarity compared to the built-in
> >>>
> >>> * Avoid the pitfalls of the current switch directive
> >>>
> >>>
> >>> ## Description ##
> >>>
> >>> The basis of this proposal is inspired by the switch statement in the
> Go
> >>> language (see https://yourbasic.org/golang/switch-statement/). Rather
> >>> than the default being to fall-through and you have to use the break
> >>> keyword to avoid it, instead the default is to not fall-through and you
> >>> have to use the fallthrough keyword to get that behavior. Having
> explicit
> >>> fall-through stops it being a pitfall whilst allowing the feature to be
> >>> used if required. Go has avoided repeating the mistake of previous
> >>> languages and presents a solution that seems obvious in hindsight.
> >>>
> >>> Approaches for adopting this could be:
> >>>
> >>> * Replace the switch directive in the next major version with the
> >> explicit
> >>> fall-through version
> >>>
> >>> * Introduce a new switch directive with a new name
> >>>
> >>> * Have a global setting for which switch directive is used / available
> to
> >>> templates
> >>>
> >>> * Add an optional parameter to the switch directive for whether it
> should
> >>> fall-through or not; its default would be a config setting. If we did
> >> this
> >>> perhaps we should consider in future being able to parse the switch's
> >> value
> >>> parameter as optional (defaulting to true), taking further inspiration
> >> from
> >>> Go.
> >>>
> >>> If we want fall-through to be explicit, it makes sense to add a
> >>> fallthrough directive to act as the inverse of the break directive. The
> >>> user would then use the break directive (as required) when using the
> >>> current mode/directive for fall-through and the fallthrough directive
> (as
> >>> required) when using the new mode/directive. For what should happen
> when
> >>> using break in the new mode/directive and fallthrough in the old
> >>> mode/directive: it could either be an error, or break will still break
> >> and
> >>> fallthrough will do nothing (or perhaps go to the next case).
> >>>
> >>>
> >>> ## Alternatives ##
> >>>
> >>> * Remove the switch directive altogether
> >>>
> >>> * Completely disallow fall-through and the break directive (have
> neither
> >>> implicit nor explicit fall-through)
> >>>
> >>> * Add a more powerful match directive that supports pattern matching
> and
> >>> takes inspiration from e.g. Java's switch expressions or Rust's pattern
> >>> syntax
> >>>
> >>> ## Future work ##
> >>>
> >>> Reinstating switch as a first-class directive would open the door to
> >>> allowing enhancements to it again.
> >>>
> >>> One (low hanging?) example: for a case directive's value parameter to
> be
> >>> an expression it sometimes requires wrapping the expression in brackets
> >>> (e.g. it doesn't for an equality comparison, but does for a greater
> than
> >>> comparison); the parser could be enhanced to remove this requirement.
> >>>
> >>>
> >>> ---
> >>> Best regards,
> >>> Simon Hartley
> >>
> >>>
> >>
> >>
> >> --
> >> Best regards,
> >
> >>
> >> Daniel Dekany
> >>
> >>
> >
> > --
> > Best regards,
> > Daniel Dekany
>
--
Best regards,
Daniel Dekany
