Re: weird macro params issue

I followed the discussion without commenting because I am not really a  
user of Freemarker. However Felix, who is a user, as I understand  
would be comfortable with the Freemarker 2.4 solution presented by  
Jonathan.

If you still do decide to implement the feature, make it well  
documented and put it on the front page, in comparisons and shoot  
outs. Make it a differentiator for Freemarker.

Some people will protest, that are used to defaults as mere constant  
values, but it will give one more reason to use Freemarker as opposed  
to other template engines for those who see the value.

On 22 mai 08, at 14:48, Jonathan Revusky <[email protected]> wrote:

> On Thu, May 22, 2008 at 3:28 PM, Attila Szegedi <[email protected]>  
> wrote:
>> On 2008.05.22., at 15:10, Tim Diggins wrote:
>>
>>> I hope you're not arguing that character count is more important  
>>> than
>>> understandability / readability / learnability.
>>
>> I'm not. As a matter of fact, to this day I prefer the old existence
>> built-ins "?default" and "?exists" for similar reasons I prefer Java
>> "extends" to C# ":" :-)
>> I don't feel that <#macro m a b=a> impacts understandability or
>> readability. To me,
>>
>> <#macro a b!>
>>  <#if !b??>
>>    <#local b=a/>
>>  </#if>
>> </#macro>
>>
>> would, honestly, be less understandable IMHO. The b=a doesn't
>> introduce any new syntax - it's your good ol' defaulted argument, the
>> only novelty is it's defaulting to value of another argument, which  
>> is
>> also visually located near it, so I don't believe it makes
>> understanding the meaning too daunting.
>
> Actually, I just realized something.
>
> Independently of whether we support this particular thing, our
> semantics are quite different from Python semantics. In python, the
> example I gave that failed:
>
> def foo(x, y=x) :
>
> Basically it fails because the default values in python are values.
> They must be constant values that can be calculated when you define
> the function.
>
> FreeMarker default values (in 2.4 also) are not actually values, they
> are expressions. (Of course, an expression that evaluates to a
> constant value is very often used.)
>
> So I guess the "what would Guido do" argument is kind of weak because
> we're already so far away. It would seem then that if the default
> values in a macro definition can be expressions (later evaluated on
> invocation) that this use case is consistent with that.
>
> So I guess my view is shifting on this. I honestly had the distinct
> impression that you were implementing this basically because it could
> be done, which of course made me nervous. The whole multipass thing
> for tricky cases might be unnecessary, and it might be better just to
> scan straightforwardly left to right as Felix suggested. Though, if
> you are implementing it, you can do it as you want as far as I'm
> concerned.
>
> JR
>
>>
>> Attila.
>>
>> --- 
>> --- 
>> -------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>>
>
> --- 
> ----------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/