Re: 2.3.33 pre-vote testing

[Denis Bredelet]

Hello,

I am talking as an outsider since I never touched the accessors configuration.

Would it make sense to have three policies?

BeanAccessorsPolicy
GetterStyleAccessorsPolicy
DefaultAccessorsPolicy (= mixed, as Simon highlighted conflicts are already 
errors so it is backward-compatible.)

— Denis.

> Le 1 avr. 2024 à 17:49, Simon Hartley  a 
> écrit :
> 
> In terms of language, for a record's read methods, Java calls them accessors.
> For beans, I'm used to the term getter, but when expanding to also describe 
> how boolean return methods are handled,
> the term accessor is again used. It seems that zero-argument non-void is 
> trying to be distinct from the term accessor,
> because that's what we believe is necessary for backwards compatibility and 
> compatibility with beans
> (and a project could have a mixture of bean and non-bean style classes).
> 
> But trying to move the problem slightly, what do you think of the following 
> idea?
> NonBeanAccessorsPolicy.XXX (as opposed to ZeroArgumentNonVoidMethodPolicy.XXX)
> Note: I've used a plural here to try to highlight we're saying the methods 
> are non-bean, rather than the classes.
> So how does this help us when there's a conflict?
> We've implied that logic for bean accessors may be being applied as well; 
> this can be supplemented with documentation.
> Also not every future option should hang off ZeroArgumentNonVoidMethodPolicy,
> since our original intent was to describe non-bean related behavior.
> 
> 
> For 2.3.32:
> * non-bean class accessors could only be methods
> * bean class accessors could be methods and properties
> * non-bean record accessors could only be methods
> * bean record accessors are generally a mistake
> 
> For 2.3.33:
> * non-bean class accessors were added to address use cases for both records 
> and classes.
> * we haven't introduced an option to turn-off bean accessors for records to 
> solve the problem for records
> * for some projects, an option to turn-off bean accessors for classes may be 
> useful,
>   but some projects would want a mixture
> * where there is a mixture here are some approaches:
>   - prefer exposing bean properties (more likely to be backwards compatible?)
>   - prefer exposing non-bean properties (would work better with records?)
>   - error (force the user to resolve ambiguity by either using a method 
> invocation or changing their Java code)
>   - expose both (collisions?)
> 
>   
> Property collisions
> ---
> 
> What happens when a record has fields/components of both active and isActive?
> record Evil(boolean active, boolean isActive) {}
> 
> With the current implementation, both of the following cause an error when 
> the "active" property is used!
> record MyRecord(boolean isActive) {
> public boolean active() {
> return false;
> }
> // implicit method isActive()
> }
> record MyRecord(boolean active) {
> public boolean isActive() {
> return false;
> }
> // implicit method active()
> }
> 
> So collisions are already there, not a potential risk.
> 
> Simon
> 
> 
> 
> 
> 
> On Monday, 1 April 2024 at 12:35:44 BST, Daniel Dekany 
>  wrote: 
> 
> 
> 
> 
> 
> I think we need the current behavior for the
> almost-backward-compatible behavior that incompatibleImprovements
> 2.3.33 promises. (Although it's "incompatible", there's a promise that
> as far as it's 2.3.x, it only enables changes that are most likely
> won't break your application, hence when someone discovers that they
> need some of the improvements it brings, they can usually crank it up,
> and get all the other improvements too, instead of people having some
> unique permutation of "improvements" enabled.) So maybe
> ZeroArgumentNonVoidMethodPolicy.PROPERTY_ONLY should be called
> PROPERTY_UNLESS_BEAN_PROP_READ_METHOD (oh my...), and
> BOTH_PROPERTY_AND_METHOD should called
> PROPERTY_UNLESS_BEAN_PROP_READ_METHOD_AND_METHOD (even funnier name).
> And then later we can introduce other policies if needed, which are
> less backward compatible, but might be seen cleaner or more obvious.
> 
> On Sun, Mar 31, 2024 at 4:49 PM Simon Hartley
>  wrote:
>> 
>> If I was trying to do something here's an idea or two
>> (please don't feel any pressure to implement this, I'm just thinking out 
>> loud):
>> 
>> How properties are implemented is from two sources: beans and simple 
>> non-voids.
>> When the logic of both is being applied, then it's not a surprise that there 
>> are some strange interactions.
>> If I could enable them separately, then I could turn off bean properties on 
>> records and have it work as I hoped.
>> 
>> Otherwise perhaps I would need to have a backwards compatibility mode which 
>> is only enabled when using the default values.
>> Or perhaps a setting which said whether beans or simple non-voids take 
>> precedence.
>> 
>> I'm more than happy with the status quo; a few rough edges aren't the end of 
>> the world.
>> I very much appreciate the effort you've already put 

Re: Request for feedback: Switch directive proposal

[Denis Bredelet]

Hi Daniel,

> #else and #ifelse have no closing tag either.

But #if does, right? Why not #on?

> Nor does #recover. That's the
> style that was chosen back then. Brevity over correctness(?).
> 
> <#on .other> would be rather strange. "Why don't they just have a keyword
> for the statement itself???". Also, developers won't invest much mental
> energy into learning a template language, so, the less surprising, the
> better.

True… one last attempt then I’ll hide again:
<#on …>
Does ellipsis count as “least surprise”?

Cheers,
— Denis. 

> 
>> On Sat, Feb 10, 2024 at 9:45 AM Denis Bredelet 
>> wrote:
>> 
>> Hi
>>> Understood.
>>> 
>>> One argument for supporting #break in #on: whitespace avoidance
>>> 
>>> Because there's not an explicit closing tag for #case or #on, the use of
>> #break in the following avoids a trailing newline:
>>> <#switch x>
>>><#case 1>1<#break>
>>><#default>not 1<#break>
>>> 
>> 
>> 1. #on should have a close tag, for that reason.
>> 2. #break should work as normal inside #on. That is to allow exiting an
>> #on directive early, for example on a condition.
>> 3. #case should not be allowed together with #on
>> 
>> I don’t know if #default should be replaced as well when using #on (it
>> doesn’t have a close tag!)
>> I suggest <#on .other>
>> 
>> Cheers,
>> — Denis.
>> 
>>> 
>>> Do we just say that if they need that then they should use #case
>> instead? It could mean that we'd never we able to fully deprecate #case.
>>> 
>>> ---
>>> Many thanks,
>>> Simon Hartley
>>> 
>>> 
>>> On Friday, 9 February 2024 at 23:29:28 GMT, Daniel Dekany <
>> daniel.dek...@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Because both #switch and #list supports #break, of course it will break
>> out
>>> from the innermost one (whether it's a #switch, or a #break).
>>> 
>>> #continue should only work with #list, however, it seems there's a bug
>>> here, and indeed, inside #switch it does the same as #break (that it's
>>> certainly present for 20 years or so).
>>> 
>>> As of #on, we just don't care about #break, it's unsupported. So it
>> should
>>> only affect #list. Similarly as #continue should work... We can't really
>>> fix that anymore for #case (or only with incomplatible_improvements...
>>> yeah, annoying), but for #on, we can fix that.
>>> 
>>> I say, we don't want to support mixing #case and #on in the same #switch.
>>> To keep things as simple as possible... (Well, if we want to do
>>> anything with #switch at all.)
>>> 
>>>> On Fri, Feb 9, 2024 at 11:36 PM Simon Hartley
>>>>  wrote:
>>>> 
>>>> 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>  
>>>><#default> Not 2
>>>>
>>>> 
>>>> 
>>>> 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
>>>>
>>>> 
>>>> 
>>>> 
>>>> 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&

Re: Request for feedback: Switch directive proposal

[Denis Bredelet]

Hi
> Understood.
> 
> One argument for supporting #break in #on: whitespace avoidance
> 
> Because there's not an explicit closing tag for #case or #on, the use of 
> #break in the following avoids a trailing newline:
> <#switch x>
> <#case 1>1<#break>
> <#default>not 1<#break>
> 

1. #on should have a close tag, for that reason. 
2. #break should work as normal inside #on. That is to allow exiting an #on 
directive early, for example on a condition. 
3. #case should not be allowed together with #on

I don’t know if #default should be replaced as well when using #on (it doesn’t 
have a close tag!)
I suggest <#on .other>

Cheers,
— Denis. 

> 
> Do we just say that if they need that then they should use #case instead? It 
> could mean that we'd never we able to fully deprecate #case.
> 
> ---
> Many thanks,
> Simon Hartley
> 
> 
> On Friday, 9 February 2024 at 23:29:28 GMT, Daniel Dekany 
>  wrote:
> 
> 
> 
> 
> 
> Because both #switch and #list supports #break, of course it will break out
> from the innermost one (whether it's a #switch, or a #break).
> 
> #continue should only work with #list, however, it seems there's a bug
> here, and indeed, inside #switch it does the same as #break (that it's
> certainly present for 20 years or so).
> 
> As of #on, we just don't care about #break, it's unsupported. So it should
> only affect #list. Similarly as #continue should work... We can't really
> fix that anymore for #case (or only with incomplatible_improvements...
> yeah, annoying), but for #on, we can fix that.
> 
> I say, we don't want to support mixing #case and #on in the same #switch.
> To keep things as simple as possible... (Well, if we want to do
> anything with #switch at all.)
> 
>> On Fri, Feb 9, 2024 at 11:36 PM Simon Hartley
>>  wrote:
>> 
>> 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>  
>> <#default> Not 2
>> 
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 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}
>> 
>> After
>> 
>> 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 
>> 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 th

Re: What's the status of FREEMARKER-35?

[Denis Bredelet]

I read the whole ramblings so you don’t have to. 

In short:

Apache FreeMarker 3 is not a viable project. 

Jonathan is working on FreeMarker 3 which is a continuation of the original 
project before the Apache fork. It uses a new parser (CongoCC) which makes it 
much easier to modify and extend the grammar. It uses POJOs instead of 
“models”. Expect big improvements in all areas. 

Jonathan is looking for collaborators who are dedicated to the project. He is 
very much against moving FreeMarker 3 to Apache. 


My personal comment:

I don’t know how Jonathan is as a project leader, but the tone of these 
ramblings does not put me at ease. If you want to take ownership it should be 
possible to fork Jonathan’s FreeMarker 3. But I expect any license change would 
have to go through him first. 

— Denis. 

> On 5 Feb 2024, at 13:46, Jonathan Revusky  wrote:
> 
> Hi Vinay. Nice to see you here.
> 
>> On Mon, Feb 5, 2024 at 11:50 AM Vinay Sajip 
>> wrote:
>> 
>> I happen to use FreeMarker, because I work on CongoCC, which uses it, but
>> I don't work on any FreeMarker codebase itself. I'm not speaking for
>> Jonathan, but my view on "why not join  hands in here ...? " might be
>> answered in part by comments Dániel Dékány made - "I think the next logical
>> step in FM3 is replacing the whole parser" - not exactly a small amount of
>> work, but something that's already been done in the project Jonathan linked
>> to.
> 
> 
> Well, yeah. Again, if one is really interested in moving the thing
> forward... But there are some niggles in all this. The rewrite of the
> parser that I undertook last summer, all of this is best understood as a
> result of using the more advanced features of CongoCC. ("Apache FreeMarker"
> still uses legacy JavaCC, as you no doubt know.) But anyway, this gets into
> some nooks and crannies of history now. You see, when I started working on
> my own "fork" (not really a fork since it wasn't a bifurcation of effort
> either!) of JavaCC back in 2008, I switched the trunk of FreeMarker
> development to using FreeCC (which is what my version was called back then,
> now it's CongoCC).
> 
> When Daniel took the project to ASF (the "incubator" yah dee dah...) he did
> not take the trunk (trunk in SVN is called "master" or now "main" in git)
> but took the older 2.3.x. maintenance branch and effectively threw away all
> the work I had been doing from 2006-2008. (So, for one thing, this Apache
> FreeMarker is based on a really, really old version of FreeMarker!)
> 
> Now, the question is why did Daniel take the older version of FreeMarker to
> ASF rather than the trunk? Did he really believe that the older codebase
> was somehow better than the newer one?
> 
> As best I can guess (though Daniel could clarify) the reason that Daniel
> threw away the latest version of the code is because that was built using
> FreeCC and he wanted to revert to using legacy JavaCC for the build. Later,
> I noticed, looking at the archives of this dev list that the whole question
> came up of using a different (perhaps actively maintained) parser generator
> rather than the JavaCC abandonware, and various possibilities were floated
> and I notice that Daniel never even mentioned the existence of FreeCC.
> That, despite the fact that there was at least one actual release that was
> built with FreeCC. So, my own theory on that whole thing is that Daniel
> threw away the most up-to-date version of the code for that reason, he
> wanted to get rid of the FreeCC dependency. And then, when the topic of
> parser generators came up, he somehow did not know that FreeCC had ever
> existed.
> 
> But anyway, all this gets back to why it would be quite difficult to merge
> my ongoing work with Apache FreeMarker, since Apache FreeMarker is based on
> the older codebase, while the FreeMarker 3 that is used in CongoCC (and its
> predecessor JavaCC21, of course) is one based on an ongoing evolution from
> the main line of FreeMarker development, the SVN trunk.
> 
> So, again, Daniel took the older obsolete codebase to ASF, the 2.3.x
> maintenance branch, and quite a bit later, when I decided to resuscitate my
> FreeCC (now CongoCC work) the FreeMarker version that I was using, that was
> under my control, was the more advanced one based on the SVN trunk. That is
> why our templates in CongoCC do not use #assign/#local but rather
> #set/#var, which IIRC I implemented at some point in 2008, or possibly even
> 2007. By the way the #set/#var is still on the wish list as a feature to be
> implemented in the "Apache FreeMarker 3" vaporware. I mean think about
> that. That feature was already implemented in 2008, 16 years ago! And it is
> on the wish list of things to have in the next major release of Apache
> FreeMarker, which now, by Daniel's admission, is never going to happen
> anyway! Can you really characterize this as anything other than a total
> train wreck?
> 
> So all of the above, though it is a bit involved to understand it, can 

Re: Request for feedback: Switch directive proposal

[Denis Bredelet]

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  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 
>>  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>
> ...
> 
> 
> 
> On Sat, Feb 3, 2024 at 6:11 PM Simon Hartley 
> 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 > .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 

Re: Pushing for minimal but quick 2.3.32

[Denis Bredelet]

Hi Daniel,

> Le 5 Jan 2023 à 13:52, Daniel Dekany  a écrit :
> 
> I'm back from this sickness - thanks for the good wishes.

Glad you are better!!

> We have the proposed 2.3.32 pushed into Git. I don't plan to add anything
> more to it. Release voting starts tomorrow (the 6th) GMT afternoon. If you
> can spot anything before(!) that, even typos in documentation, that will
> still fit in. So please go ahead, if you can, and thank you for any help!
> 
> Changes and all the generated documentation for your convenience:
> https://freemarker.apache.org/builds/2.3.32-preview/docs/versions_2_3_32.html

Can I just report typos here?

Release notes:

prevision -> precision

different conversions as in most languages -> different conversions than in 
most languages

javaSctringEsc -> javaStringEnc
(I suppose)

— Denis.

> 
> On Sun, Jan 1, 2023 at 2:40 PM Jacques Le Roux 
> wrote:
> 
>> Hi Daniel,
>> 
>> Our brain is dragging up much energy. I wish you will get enough time to
>> rest, heal and have a very good 2023 new year.
>> 
>> Jacques
>> 
>> Le 01/01/2023 à 00:20, Daniel Dekany a écrit :
>>> if my health allows it. I'm quite sick.
>> 
> 
> 
> -- 
> Best regards,
> Daniel Dekany

Re: Pushing for minimal but quick 2.3.32

[Denis Bredelet]

Hello Daniel,

> Le 31 déc. 2022 à 23:20, Daniel Dekany  a écrit :
> 
> I'm forward porting the changes from 2.3-gae into 3.0 as a form of code
> self-review. Especially in case nobody else takes a look. I will try to do
> that with CFormat/?c/?cn tomorrow, if my health allows it. I'm quite sick.
> Not sure if I will be able to proceed next week with FREEMARKER-35.

I hope you get better soon! Wishing you good health for this new year 2023.

Regards,
— Denis.

> On Tue, Dec 27, 2022 at 12:25 AM Daniel Dekany  wrote:
> 
>> OK, it has grown to be not that minimalistic after all. Nowadays I see
>> people suffering with generating JSON, in particular string literals that
>> can be null. With 2.3.31 (the old version) it's like this:
>> 
>> {
>>...
>>"fullName": <#if
>> user.fullName??>"${user.fullName?json_string}"<#else>null
>>...
>> }
>> 
>> So I wanted to offer some new built-in for that, and it went further than
>> I anticipated. Because, I realized that I can say that ?c generates
>> literals in a target computer language, and therefore someString?c could
>> generate a string literal in that computer language (a quoted, escaped
>> thing). Currently ?c doesn't support strings, so that's backward
>> compatible. So I generalized ?c a bit, which caused further changes at
>> many places. Like I had to add the c_format setting to specify the target
>> computer language.
>> 
>> Then I also added a new built-in, ?cn, for "C Nullable", which will output
>> a null literal if its left side operand is a null/missing value (?c just
>> dies with missing value error). I know, yet another cryptic shorthand, but
>> in the use cases where these are needed, you often use them a lot. Also ?c
>> is already like that. So now the earlier example is reduced to this:
>> 
>> {
>>...
>>"fullName": ${user.fullName?cn}
>>...
>> }
>> 
>> 
>> Of course ?cn will work with numerical and boolean values as well, as it's
>> the same as ?c, except when it comes to handling null/missing values. At
>> places where you don't expect null/missing values, you should use ?c
>> instead of ?cn.
>> 
>> Updated change log/documentation is here:
>> https://freemarker.apache.org/builds/2.3.32-preview/docs/versions_2_3_32.html
>> 
>> Feedback is welcome!
>> 
>> I might add a bit more, but not much more, as I should wrap up 2.3.32, and
>> then go on with java.time support.
>> 
>> 
>> On Fri, Dec 16, 2022 at 1:07 PM Daniel Dekany  wrote:
>> 
>>> Hi,
>>> 
>>> I'm adding some smaller changes to the 2.3-gae branch, so we can do a
>>> release relatively quickly, without waiting for the ever dragging java.time
>>> support. I hope it will be ready for voting in a few days, which means that
>>> it can be released this year.
>>> 
>>> Here's the change log so far... but it will grow. The changes related to
>>> ?c are already quite substantial, so take a look if you can:
>>> 
>>> https://freemarker.apache.org/builds/2.3.32-preview/docs/versions_2_3_32.html
>>> 
>>> After the voting (in a few days if all goes well), I will continue with
>>> java.time support, which will be part of the next release after this coming
>>> 2.3.32 release.
>>> 
>>> 

Re: java.time.LocalDate support for Freemarker

[Denis Bredelet]

Hi Daniel,

> Le 17 févr. 2022 à 08:40, Daniel Dekany  a écrit :
> 
> Just to keep us updated... This wasn't abandoned, but dragging. Part of the
> reason is that I keep discovering complications that need to be addressed.
> But it will be done, and when it's done, that will be released as soon as
> possible of course.

That sounds great!

More comments below.
> On Mon, Dec 27, 2021 at 10:47 PM Daniel Dekany 
> wrote:
> 
>> Now the "translating SimpleDateFormat pattern syntax to DateTimeFormatter
>> pattern syntax" part is done. Actually it parses the pattern, and builds a
>> DateTimeFormatter from it directly (so there's no translated pattern). It
>> seems to work well enough (after quite a few corner cases were addressed),
>> which is a relieft, as this was crucial for using common format settings
>> among Date-s and java.time Temporal-s.
>> 
>> Will continue with the fancier extended aka. "version 2" format. See
>> question about its syntax in previous mail, if you want to influence how
>> it will be.
>>> … ...
>>>   - version:
>>>  - "1": SimpleDateFormat syntax, which is also the default
>>>  - "2": for  DateTimeFormatter syntax + FreeMarker
>>>  extensions (which makes semicolon reserved). Example: 
>>> 'HH:mm[X];version=2'
>>>   - for${Type}, like forLocalTime: Specify a different pattern if the
>>>   value class is this
>>> 
>>> Good news is, these can be added without breaking backward compatibility,
>>> and without extra setting to enable the extended syntax, because the letter
>>> "v" in "version", and "f" in "for${Type}" (and some more letters) are
>>> invalid pattern characters for SimpleDateFormat.
>>> 
>>> I wonder if ";version=2" is good. While something like
>>> ";javaDotTimePatternSyntax=true" is more self explanatory, it's also
>>> comically verbose. So, I'm afraid people will have to search for the
>>> meaning with any sane syntax we can come up with. But if they have to
>>> anway, what if we go wilder, and say that the new syntax is indicated with
>>> an initial "v2:", as in "v2:HH:mm[X]". It's less verbose. Also, it avoids
>>> the somewhat confusing behavior that wherever you put ";version=2", it
>>> applies to the whole pattern. WDYT? Any other ideas?

I am OK with that idea.

>>> Different...  FREEMARKER-35 now also handles adjusting the Java format
>>> time styles (short, medium, long, full) for LocalDateTime, LocalTime, and
>>> OffsetTime. Before that, you often ended up with runtime error, either
>>> because the style wanted to show the zone that's not available in local
>>> temporal, or because the style did not show the offset that is often to
>>> display an OffsetTime if DST is a possibility. Earlier I said that I add
>>> settings to set the upper and lower bounds of the time style for these
>>> types. Instead, I made this adjustment entirely dynamic and automatic, and
>>> there are no settings to worry about. I realized it has to be like that,
>>> because what the proper closest usable time style depends on the locale, or
>>> even Java version and local Java customizations.
>>> 
>>> 
>>> On Mon, Dec 13, 2021 at 1:01 PM Geoffrey De Smet 
>>> wrote:
>>> 
 Good point, Daniel
 
 I agree on the need for the mixed situation support.
 
 About the same pattern, I also agree losing simplicity is not worth it
 and BC is needed for datetime_format, date_format, and time_format.
 Having access to LocalDate etc will be well worth that wrinkle.

Yes

 With kind regards,
 Geoffrey De Smet
 On 13/12/2021 12:27, Daniel Dekany wrote:
 … ...
>  So you don’t want to
> consider if it's a java.util.Date, or a LocalDateTime, or an
> OffsetDateTime, or a ZonedDateTime, or an Instant. Most of the time at
> least, you don't want to present them differently. There I intend to 
> remove
> all these new settings, except year_format, and year_month_format.
> Everything else will be governed by just datetime_format, date_format, and
> time_format.
> 
> What do you guys think?
> 
> +1 (non-contributor)

Yes

— Denis.

Re: Apache FreeMarker - Sharing Is Caring ...

[Denis Bredelet]

Hello Woonsan,

>> On Tue, Dec 3, 2019 at 5:06 AM Siegfried Goeschl
>>  wrote:
>> ---8<--- snip --->8---
>>> Regarding remarks (improvement ideas)
>>> 
>>> Having an easy way to add custom tools would be nice but a bit tricky
>> 
>> Right. I was imagining a Spring Boot based app which can take
>> advantage of extra libraries loading, application configuration,
>> executable jar distribution, etc. But I admit that I didn't consider
>> all different environment issues.
>> So, I'm not suggesting we should adopt something like spring-boot
>> right now, but just want to share what I was thinking below.

The settings described below are quite nice, it should be simple enough to 
adopt the functionality without depending on Spring. 

Just use a different configuration file name by default. Make the tool 
compatible with current version of Spring config file. 

If used with Spring, then pass the settings down to it. 

Does that sound good?
— Denis. 

>> 
>>> 
>>> * How to pick up custom tools - config file versus class path scanning? 
>>> What dependencies to pull in?
>> 
>> As the current tool objects such as XmlTool are just POJO beans, it
>> seems nice if we can configure extra beans _easily_.
>> In spring-boot apps, we can provide (a) the default application
>> configuration file (e.g, application.yaml), (b) people can override
>> some properties through command line (e.g,
>> "-Dtools=com.example.tools.MyTool,com.example.tools.MyTool2"), or (c)
>> they can replace the whole configuration file through command line
>> (e.g, --spring.config.location=my.yaml).
>> And spring-boot allows to specify extra classpah too. i.e, java
>> -Dloader.path="mylib/" ...
> 
> Just in case, I have a spring-boot app project, which helps migrate
> Apache Jackrabbit binary data store from one to another:
> - https://github.com/woonsan/jackrabbit-datastore-migration
> You can find some examples about the framework features in the README.md.
> 
>> 
>> I'm not sure yet whether this kind of approach - simple executable jar
>> with depending on the framework's feature - may bring other drawbacks
>> that do not exist with your current solution.
>> 
>> Please share what you think - pros and cons.
>> 
>> Cheers,
>> 
>> Woonsan
>> 
>>> * How to integrate custom libs with the generated wrapper scripts - I would 
>>> like to cleanly separate out-of-the-box freemarker-cli from user-specific 
>>> changes, e.g. I support loading FreeMarker templates from 
>>> “~/.freemarker-cli/templates”
>>> 
>>> Using FreemarkerTask in a different environment
>>> 
>>> * No problem to keep a shared “Configuration”
>>> 
>>> Thanks in advance,
>>> 
>>> Siegfried Goeschl

Re: Feature Request for builtin "replace"

[Denis Bredelet]

Hi Michael 

> On 22 Oct 2019, at 15:50, Barrie Selack  wrote:
> 
> Michael,
> 
> Could you use remove_begining and remove_ending?
> 
> https://freemarker.apache.org/docs/ref_builtins_string.html#ref_builtin_remove_ending
> 
> Barrie
> 
> 
> 
> On Tue, Oct 22, 2019 at 10:31 AM Riehemann, Michael <
> michael.riehem...@coremedia.com> wrote:
> 
>> Hello,
>> 
>> I have a Feature Request for the string built-in "replace".
>> 
>> This built-in has some additional flags, see
>> https://freemarker.apache.org/docs/ref_builtins_string.html#ref_builtin_string_flags
>> 
>> Example:
>> We have string, in which we want to remove the first and last appearance
>> of a substring.
>> The first one is possible, but not the last one. Or do I miss something
>> here?

You could use a combination of keep_before_last and keep_after_last :)

— Denis. 

>> Code:
>> <#assign testString="start some text start end some more lines end again"
>> />
>> ${testString?replace("start", "", "f")} = some text start end some more
>> lines end again
>> 
>> It would be nice to have a flag "l" to get the last one.
>> ${testString?replace("end", "", "l")} = start some text start end some
>> more lines again
>> 
>> 
>> What do you think?
>> 
>> Thanks in advance,
>> 
>> Michael Riehemann
>> 

Re: Lambda Expressions - filter list without <#list> directive

[Denis Bredelet]

> Le 2 juil. 2019 à 20:29, Pete Helgren  a écrit :
> 
> As a more casual Java programmer, the "where" option is much clearer to me. I 
> spend more time using FM syntax than changing the Java underneath, so from a 
> "fading memory" standpoint, "where" would lead to fewer "What the?" 
> moments,  for me at least.

I prefer « where » for the reasons Daniel mentioned, also SQL uses WHERE.

I think SQL has as many users as Javascript, no?

— Denis.

> 
> Pete Helgren
> www.petesworkshop.com
> GIAC Secure Software Programmer-Java
> Twitter - Sys_i_Geek  IBM_i_Geek
> 
> On 7/2/2019 2:08 PM, Christoph Rüger wrote:
>> Good point. Seems you are not the first ones stumbling on that one.
>> I quickly searched around and found:
>> 
>> Similar question on SO:
>> https://stackoverflow.com/questions/45939202/filter-naming-convention
>> Javascript: filter :
>> https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Array/filter
>> Spark SQL -> "where" is an alias for "filter":
>> https://stackoverflow.com/a/33887122/135535
>> 
>> -> search for "filter" or "where" on
>> https://spark.apache.org/docs/1.5.2/api/scala/index.html#org.apache.spark.sql.DataFrame
>> R Statistics Language : filter
>> https://cran.r-project.org/web/packages/dplyr/vignettes/dplyr.html#filter-rows-with-filter
>> 
>> Python: filter https://www.geeksforgeeks.org/filter-in-python/
>> Ruby: they use select:
>> https://www.codementor.io/tips/8247613177/how-to-filter-arrays-of-data-in-ruby
>> Kotlin: filter:
>> https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/filter.html
>> 
>> This languages rank in the upper area of the Stackoverflow survey:
>> https://insights.stackoverflow.com/survey/2019#technology-_-programming-scripting-and-markup-languages
>> 
>> I agree that "where" reads pretty nice. I like it. But "filter" seems to be
>> found in multiple common languages supporting lambdaish syntax.
>> Python and R is especially common in the data science / statistics
>> community, which are different target group than e.g. Java-Programmers.
>> Also web-developers these days are doing lots of javascript to build "html"
>> websites / templates - and javascript also uses "filter".
>> 
>> My vote would still go for "filter", because I think we are working on
>> lists of objects and objects are closer to "programming" than to "sql".
>> Maybe the "where"-alias would be a compromise - but might also be confusing
>> two have both.
>> 
>> What do others think?
>> 
>> Thanks
>> Christoph
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Am Di., 2. Juli 2019 um 20:27 Uhr schrieb Daniel Dekany >> :
>>> I wonder if "filter" is a good name. For Java 8 programmers it's
>>> given, but otherwise I find it confusing, as it's not clear if you
>>> specify what to filter out, or what to keep. Worse, I believe in every
>>> day English "foo filter" or "filters foo" means removing foo-s because
>>> you don't want them, which is just the opposite of the meaning in
>>> Java. So I think "where", which is familiar for many from SQL (for
>>> most Java programmers as well, but also for non-Java programmers),
>>> would be better. Consider:
>>> 
>>>   users?filter(user -> user.inactive)
>>> 
>>> VS
>>> 
>>>   users?where(user -> user.inactive)
>>> 
>>> The first can be easily misunderstood as removing the inactive users,
>>> while the meaning of the second is obvious.
>>> 

Re: Aw: Re: Freemaker for Javascript?

[Denis Bredelet]

Hi Ingo

> Hallo Daniel,
> thank you for your answer. The next days I will think about this topic. Maybe 
> it makes sense to
> develop a very fist lite version of your FM in JS.

How about converting Java to Webassembly? At least the core. 

— Denis. 

> 
> Ingo
> 
> 
> 
> 
>> Gesendet: Dienstag, 19. Februar 2019 um 22:38 Uhr
>> Von: "Daniel Dekany" 
>> An: "Ingo Mahnke" 
>> Betreff: Re: Freemaker for Javascript?
>> 
>> I'm not aware of such activity. Also, while implementing something
>> similar to FreeMarker in JavaScript is possible, it would be very
>> difficult to implement something that's close to the Java version (in
>> terms of template portability), because of the lot of built-ins and
>> date formatting, etc. (For something minimalist like Mustache it's of
>> course much easier to do.)
>> 
>> 
>> Tuesday, February 19, 2019, 2:10:17 PM, Ingo Mahnke wrote:
>> 
>>> Hallo, we use Freemaker a lot. Every day a couple of hours.
>>> Currenty we hat to make a server requests to render templates with
>>> freemaker, because freemaker runs on the server.
>>> We don't want this in the future.
>>> 
>>> Does anyone know a project which at least starts to port freemaker to 
>>> javascript so that
>>> rendering within the browser could possible - one day.
>>> 
>>> Other template engines,e.g. liquid or mustache have ports for
>>> different languages e.g. javascript.
>>> We don't want to switch to an other template enginge - we love freemaker.
>>> 
>>> I googled a time but found nothing usefull.
>>> 
>>> Thank you 
>>> Ingo
>>> 
>> 
>> -- 
>> Thanks,
>> Daniel Dekany
>> 
>> 

Re: Spread operator (splat operator) in FTL

[Denis Bredelet]

Hi,

> On 25 Nov 2018, at 17:52, Daniel Dekany  wrote:
> 
>> The extra parameters don’t need to be made into a map. You could just use 
>> this syntax:
>> 
>> <@my.fancyInput?apply(commonParams) type='text' size=10 />
> 
> Good point! Although then that's some form of currying, not "apply",
> as the directive is not invoked by the built-in. But it's not normal
> currying either, as we don't specifying the parameters directly. I
> wonder what the built-in name should be. Maybe "spread_args":
> 
> <@my.fancyInput?spread_args(commonParams) type='text' size=10 />
> 
> Still not as nice as the specialized syntax, but certainly a better
> compromise than adding new syntax.

If I may do another suggestion, can we call this built-in “?set_args” or 
“?preset”?

I feel “spread args” could be too technical.

— Denis.

Re: Spread operator (splat operator) in FTL

[Denis Bredelet]

Hi Daniel,

> Le 24 nov. 2018 à 20:11, Daniel Dekany  a écrit :
> 
> Friday, November 23, 2018, 2:54:05 PM, Denis Bredelet wrote:
> 
>> Hi Daniel,
>> 
>> Note this discussion:
>> https://issues.apache.org/jira/browse/FREEMARKER-107
>> 
>> That looks like func.apply() in Javascript right?
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax
> 
> func.apply() gives identical functionality, but no syntax to make it
> succinct. Like consider (assuming the syntax is **kwargs, like in Python)
> 
>  <#assign commonParams = { 'style': 'foo', 'align': 'left' }>
>  ...
>  <@my.fancyInput type='text' size=10 **commonParams />
> 
> With function.apply-style it's something like:
> 
>  <@my?fancyInput?apply({ 'type': 'text', 'size': 10 } + commonParams) />
> 
> So that does the same without new syntax (it only adds a new built-in,
> "apply"), but is more verbose, and it changes the look-and-feel of the
> call a lot, just because you happen to need some dynamically added
> parameters there.

The extra parameters don’t need to be made into a map. You could just use this 
syntax:

<@my.fancyInput?apply(commonParams) type='text' size=10 />

>> -- Denis.
>> 
>> Another interesting and long missing feature. The question is what the
>> syntax should be, especially we need it both for by-position and
>> by-name parameter passing.
>> 
> 
> -- 
> Thanks,
> Daniel Dekany
> 

Re : Spread operator (splat operator) in FTL

[Denis Bredelet]

Hi Daniel,



Note this discussion:
https://issues.apache.org/jira/browse/FREEMARKER-107



That looks like func.apply() in Javascript right?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax
 
-- Denis.


Another interesting and long missing feature. The question is what the
syntax should be, especially we need it both for by-position and
by-name parameter passing.

--
Thanks,
Daniel Dekany

Re : Re: Lambda Expressions - filter list without <#list> directive

[Denis Bredelet]

Hi,


Le 9 novembre 2018 à 22:36, Christoph Rüger  a écrit :


Am Fr., 9. Nov. 2018 um 22:55 Uhr schrieb Daniel Dekany 

Re : [FM3] Syntax-related settings, and file extensions again.

[Denis Bredelet]

Hi Daniel,


Le 25 mars 2018 à 17:52, Daniel Dekany  a écrit :


In FM3 there's a configuration (ParsingConfiguration to be precise)
setting called "templateLanguage" (of type TemplateLanguage). This is
kind of a dummy ATM, but will be important in supporting multiple
template languages in FM3.

...


So, are you saying this solution is the most extensible while remaining 
reasonably simple?



Thanks,

-- Denis.