Re: weird macro params issue

Tim Diggins wrote:

>
> I would rather have the clarity and  understandable predictability of  
> python's scoping and execution model to the confusion that the added  
> features bring to that. I'm not sure that 'if I don't use it, it won't  
> affect me', but I can't prove that.
>   

I'm absolutely with you. But note that we are not really talking about a
new feature, as the defaulting to another parameter already works, at
least in some situations. It would be perfectly possible to implement
this feature in a sane and predictable way. So the question is whether
it should always work or always fail.

> For the second use case, wouldn't it be better to find a way to  
> support 'uninitialized variables' (like null) and then do explicit  
> assignment within the body of the macro (as you suggested).
>   

Yes. This would work equally well for the first use-case.

> and isn't the 'null unawareness' of FreeMarker really down to the fact  
> that there isn't a ?isNull or ?null builtin for all variables (instead  
> you have to use the ?exists builtin, which is, I think, functionally  
> identical, but seems semantically odd). Maybe creating ?null as an  
> alias to ?exists might help?
>   

No, not really. The problem is that you can't pass an undefined value to
a macro, while it is possible to pass an undefined value to a Java
method via myJavaObject.foo(nullArg).

My preferred solution would be, if it was possible to mark parameters as
optional. This way there would be no need to introduce a new keyword
(like "null").

<#macro foo bar baz!>
    <#if !baz??>
        <#local baz = bar />
    </#if>
</#macro>

If this was possible, I'd vote for not supporting the "weird defaults"
at all.

-Felix

-------------------------------------------------------------------------
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/