Re: [vote] Opinions about conditional built-in names?

For now I have renamed

  exp?choose(whenTrue, whenFalse)

to

  exp?then(whenTrue, whenFalse)

because this time that was the most popular option (last year it was
?choose for some reason). I still wonder if we should sacrifice some
terseness for being more understandable with:

  exp?then_else(whenTrue, whenFalse).

If you hate to type "_", take into account that in 2.3.23 you can
already write templates in camel case, which will be probably the
recommended convention sooner or later. Then you have:
exp?thenElse(whenTrue, whenFalse)

Opinions?

-- 
Thanks,
 Daniel Dekany


Wednesday, June 3, 2015, 12:58:56 AM, Daniel Dekany wrote:

> Wednesday, June 3, 2015, 12:00:09 AM, Jaime Garza wrote:
>
>> thenElse is not in the style of other composite words for
>> built-ins, like cap_first, right? The style dictates ?then_else
>
> Yes, I meant then_else. (Or... in fact, in 2.3.23 you can use camel
> case as well, but then you need to use camel case for everything
> that's defined by Freemarker.)
>
>> Personally I like boolean?if(true-expr, false-expr)
>
> So my concern with ?if is this that loggedIn?if(user.name, "unknown")
> can be easily misread like this, as you read it left-to-right: (We
> are) logged in IF user.name is "unknown". At last the "logged in IF
> user.name" part is especially easy to read into it, and is already the
> opposite of what the expression means (IF logged in then user.name).
>
>> Very concise.
>>
>> Jaime Garza
>>
>> -----Original Message-----
>> From: Daniel Dekany [mailto:[email protected]] 
>> Sent: Tuesday, June 02, 2015 2:20 PM
>> To: FreeMarker-devel
>> Subject: Re: [Freemarker-devel] [vote] Opinions about conditional built-in names?
>>
>> Tuesday, June 2, 2015, 1:54:24 PM, Raymond Auge wrote:
>>
>>> Having reviewed those and due to my preferring readability over 
>>> anything else, I would still lean toward:
>>>
>>> someBoolean?then(whenTrue, whenFalse)
>>>
>>> But would actually prefer the more expressive:
>>>
>>> someBoolean?ifelse(whenTrue, whenFalse)
>>
>> Then rather someBoolean?thenElse(whenTrue, whenFalse), isn't it?
>> Though that even longer...
>>
>> What should I notice in that Wikipedia article?
>>
>> --
>> Thanks,
>>  Daniel Dekany
>>
>>
>>> I'd learn to deal with the first of course.
>>>
>>> - Ray
>>>
>>> On Tue, Jun 2, 2015 at 7:47 AM, Raymond Auge <[email protected]> wrote:
>>> I lean to "then".
>>>
>>> But before deciding maybe a quick look over these: http://en.wikipedia.org/wiki/%3F:
>>>
>>> - Ray
>>>
>>> On Tue, Jun 2, 2015 at 3:01 AM, Daniel Dekany <[email protected]> wrote:
>>> OK, so that's like a vote for "then". Anyone else has an opinion? Or
>>> even just a vote on the name you prefer?
>>>
>>> someBoolean?then(whenTrue, whenFalse)someBoolean?then(whenTrue, whenFalse)
>>> or
>>> someBoolean?choose(whenTrue, whenFalse)
>>> or
>>> something else?
>>>
>>> --
>>> Thanks,
>>>  Daniel Dekany
>>>
>>>
>>> Monday, June 1, 2015, 9:41:49 PM, Woonsan Ko wrote:
>>>
>>>> On 6/1/15 3:26 PM, Daniel Dekany wrote:
>>>>> Sunday, May 31, 2015, 7:50:20 PM, Woonsan Ko wrote:
>>>>>
>>>>>> I personally prefer having the default value option inside the
>>>>>> parenthesis, without having to depend on the default value after '!'.
>>>>>> So, I like the idea the odd number of parameters for a default value.
>>>>>>
>>>>>> Regarding the original question about 'switch' and 'choose', I like the
>>>>>> 'switch' very much, but I'm not sure if 'choose' is a good name for
>>>>>> ternary operator. In XSL, 'choose' means just one choice of the
>>>>>> 'switch'.
>>>>>
>>>>> Actually, in XSLT "choose" stands for "switch" (and "when" stands for
>>>>> "case"). But that just proves how confusing this word is...  
>>>>
>>>> Oh you're right. Long time passed after I wrote XSL files last.  
>>>>
>>>>>
>>>>>> 'choose' sounds like related to one of the 'multiple' choices
>>>>>> to me.
>>>>>
>>>>> Well, I'm also unhappy with "choose", I just couldn't find better
>>>>> yet... What do you think about "then". Apart from the lack of "else"
>>>>> in it, it reads quite fluently: loggedIn?then(user.name, "unknown").
>>>>
>>>> Yeah, "then" sounds better to me than anything else.
>>>>
>>>>>
>>>>>> Another option to consider might be 'iif' [1], which seems a bit clearer
>>>>>> to me than 'either' and others.
>>>>>>
>>>>>>     someBoolean?iif(whenTrue, whenFalse)
>>>>>>
>>>>>> Just my two cents,
>>>>>
>>>>> I have played that idea back then, but I'm afraid very few knows what
>>>>> does "iif" stands for. Also loggedIn?iif(user.name, "unknown") can be
>>>>> easily misread like: we are logged in IF user.name is "unknown".
>>>>
>>>> Agreed. Not sound fluent.
>>>>
>>>> Kind regards,
>>>>
>>>> Woonsan
>>>>
>>>>>
>>>>>> Woonsan
>>>>>>
>>>>>> [1] http://en.wikipedia.org/wiki/IIf
>>>>>>
>>>>>> On 5/30/15 6:02 AM, Daniel Dekany wrote:
>>>>>>> And regarding the semantics of ?switch... as it sands now, if there's
>>>>>>> no matching choice, that will be an exception that says:
>>>>>>>
>>>>>>>   The value before ?switch(case1, value1, case2, value2, ...) didn't
>>>>>>>   match any of the case parameters, and there was no default value
>>>>>>>   parameter (an additional last parameter) either.
>>>>>>>
>>>>>>> So, if you have an odd number of parameters, then the last one is like
>>>>>>> the default branch of switch in Java.
>>>>>>>
>>>>>>> I have also considered just returning null if there's no match, and
>>>>>>> then one can write ?switch(...)!theDefault, but then if someone
>>>>>>> doesn't give a default, the error messages will just say that
>>>>>>> ?switch(...) has evaluated to null/missing, which many users won't
>>>>>>> understand why's happening. Also it has the same problems as
>>>>>>> ?then(this)!that had.


------------------------------------------------------------------------------