String comparisons

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

String comparisons

Jaime Garza
In the code on ComparisonExpression:

        else if(ltm instanceof TemplateScalarModel && rtm instanceof TemplateScalarModel) {
            if(operation != EQUALS && operation != NOT_EQUALS) {
                throw new TemplateException("Can not use operator " + opString + " on string values.", env);
            }
            String first = EvaluationUtil.getString((TemplateScalarModel)ltm, left, env);
            String second = EvaluationUtil.getString((TemplateScalarModel)rtm, right, env);
            comp = env.getCollator().compare(first, second);
        }

Collator supports "less", "less than", "greater" and "greater than" semantics.  

What is the caveat on not allowing anything but equals and not equals?  There must be a reason.

(Having all the semantic behaviors would be a great way to deal with date comparisons when I need to convert dates to text, and back to a date.)

Thanks
Jaime

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: String comparisons

Daniel Dekany
Wednesday, January 30, 2013, 10:43:30 PM, Jaime Garza wrote:

> In the code on ComparisonExpression:
>
>         else if(ltm instanceof TemplateScalarModel && rtm instanceof TemplateScalarModel) {
>             if(operation != EQUALS && operation != NOT_EQUALS) {
>                 throw new TemplateException("Can not use operator "
> + opString + " on string values.", env);
>             }
>             String first =
> EvaluationUtil.getString((TemplateScalarModel)ltm, left, env);
>             String second =
> EvaluationUtil.getString((TemplateScalarModel)rtm, right, env);
>             comp = env.getCollator().compare(first, second);
>         }
>
> Collator supports "less", "less than", "greater" and "greater than" semantics.
>
> What is the caveat on not allowing anything but equals and not equals?  There must be a reason.

The collators of the current locale(!) could be used technically (but
with what settings?). But it's hard to find a reason to compare two
strings in a template for anything but equality, so when FreeMarker
runs into another kind of comparison, it's very likely that it's just
the result of bug in the application. Typically, the user meant to
compare two numbers or dates which come from XML or as HTTP request
parameters, but have forgotten to parse them to number or date. A
string comparison would silently give the wrong answer. It's
dangerous, especially as there are cases where it accidentally gives
the good answer, and that will happen while you are testing, of
course... So it's better to throw an exception.

> (Having all the semantic behaviors would be a great way to deal
> with date comparisons when I need to convert dates to text, and back to a date.)

You want to compare dates in string form? I guess that happens to work
with ISO dates... but not with most date formats.

> Thanks
> Jaime

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: String comparisons

Jaime Garza
I understand the dangers, but a string is a string and we developers are used to comparing strings since the times of strcmp.  Also I saw that in Environment we get the collator from the environment's locale, so the locale is clearly understood. Assuming it would be a bug is far from reality if you need to do some simple string sorting.

With string comparison I could do

<#if .now?string("yyyyMMdd") > "20130130">
After January 30 2013
</if>

And that is far from a bug.  The problem is, I am without .now?date > aDate?date, so I thought of going the string way, but then strings are restricted and this is what I have to do:

.now?string("yyyyMMdd")?date("yyyyMMdd")

To get a date with only the date portion.

Not very pretty.  Since I am writing a code generator, the results are very verbose, and perhaps internally inefficient.

Jaime

-----Original Message-----
From: Daniel Dekany [mailto:[hidden email]]
Sent: Wednesday, January 30, 2013 2:26 PM
To: FreeMarker-devel
Subject: Re: [Freemarker-devel] String comparisons

Wednesday, January 30, 2013, 10:43:30 PM, Jaime Garza wrote:

> In the code on ComparisonExpression:
>
>         else if(ltm instanceof TemplateScalarModel && rtm instanceof TemplateScalarModel) {
>             if(operation != EQUALS && operation != NOT_EQUALS) {
>                 throw new TemplateException("Can not use operator "
> + opString + " on string values.", env);
>             }
>             String first =
> EvaluationUtil.getString((TemplateScalarModel)ltm, left, env);
>             String second =
> EvaluationUtil.getString((TemplateScalarModel)rtm, right, env);
>             comp = env.getCollator().compare(first, second);
>         }
>
> Collator supports "less", "less than", "greater" and "greater than" semantics.
>
> What is the caveat on not allowing anything but equals and not equals?  There must be a reason.

The collators of the current locale(!) could be used technically (but with what settings?). But it's hard to find a reason to compare two strings in a template for anything but equality, so when FreeMarker runs into another kind of comparison, it's very likely that it's just the result of bug in the application. Typically, the user meant to compare two numbers or dates which come from XML or as HTTP request parameters, but have forgotten to parse them to number or date. A string comparison would silently give the wrong answer. It's dangerous, especially as there are cases where it accidentally gives the good answer, and that will happen while you are testing, of course... So it's better to throw an exception.

> (Having all the semantic behaviors would be a great way to deal with
> date comparisons when I need to convert dates to text, and back to a
> date.)

You want to compare dates in string form? I guess that happens to work with ISO dates... but not with most date formats.

> Thanks
> Jaime

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: String comparisons

Daniel Dekany
Wednesday, January 30, 2013, 11:53:23 PM, Jaime Garza wrote:

> I understand the dangers, but a string is a string and we developers
> are used to comparing strings since the times of strcmp. Also I saw
> that in Environment we get the collator from the environment's
> locale, so the locale is clearly understood. Assuming it would be a
> bug is far from reality if you need to do some simple string
> sorting.

It's very unlikely that you implement a sorting algorithm in a
template. Plus it's not a statically typed language, so the problem I
have mentioned (numbers or dates accidentally left in string form) is
very real.

> With string comparison I could do
>
> <#if .now?string("yyyyMMdd") > "20130130">

(BTW, you could convert those further to numbers, but hen it just got
uglier for sure...)

> After January 30 2013
> </if>
>
> And that is far from a bug.

It's about chances. A lot of people tries to compare numbers coming
from XML and such, very few tries to do the above.

> The problem is, I am without .now?date > aDate?date, so I thought of
> going the string way, but then strings are restricted and this is
> what I have to do:
>
> .now?string("yyyyMMdd")?date("yyyyMMdd")
>
> To get a date with only the date portion.
>
> Not very pretty.  Since I am writing a code generator, the results
> are very verbose,

In such cases (something is too verbose and often needed) you should
use #function for example. Or TemplateMethodModelEx for higher
performance.

> and perhaps internally inefficient.

You want to do some calendar math here. It has nothing to do with
string comparison really. The problem here is simply that FreeMarker
has no built-ins for calendar math (and that's the thing that should
be fixed in FM). I suggest addressing that by adding some methods for
that (TemplateMethodModelEx). All other solutions are hacks (like,
converting to string and then back to date, or even converting to
string and compare strings).

--
 Best regards,
 Daniel Dekany

> Jaime
>
> -----Original Message-----
> From: Daniel Dekany [mailto:[hidden email]]
> Sent: Wednesday, January 30, 2013 2:26 PM
> To: FreeMarker-devel
> Subject: Re: [Freemarker-devel] String comparisons
>
> Wednesday, January 30, 2013, 10:43:30 PM, Jaime Garza wrote:
>
>> In the code on ComparisonExpression:
>>
>>         else if(ltm instanceof TemplateScalarModel && rtm instanceof TemplateScalarModel) {
>>             if(operation != EQUALS && operation != NOT_EQUALS) {
>>                 throw new TemplateException("Can not use operator "
>> + opString + " on string values.", env);
>>             }
>>             String first =
>> EvaluationUtil.getString((TemplateScalarModel)ltm, left, env);
>>             String second =
>> EvaluationUtil.getString((TemplateScalarModel)rtm, right, env);
>>             comp = env.getCollator().compare(first, second);
>>         }
>>
>> Collator supports "less", "less than", "greater" and "greater than" semantics.
>>
>> What is the caveat on not allowing anything but equals and not equals?  There must be a reason.
>
> The collators of the current locale(!) could be used technically
> (but with what settings?). But it's hard to find a reason to compare
> two strings in a template for anything but equality, so when
> FreeMarker runs into another kind of comparison, it's very likely
> that it's just the result of bug in the application. Typically, the
> user meant to compare two numbers or dates which come from XML or as
> HTTP request parameters, but have forgotten to parse them to number
> or date. A string comparison would silently give the wrong answer.
> It's dangerous, especially as there are cases where it accidentally
> gives the good answer, and that will happen while you are testing,
> of course... So it's better to throw an exception.
>
>> (Having all the semantic behaviors would be a great way to deal with
>> date comparisons when I need to convert dates to text, and back to a
>> date.)
>
> You want to compare dates in string form? I guess that happens to
> work with ISO dates... but not with most date formats.
>
>> Thanks
>> Jaime


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel