Re: weird macro params issue

On 22 May 2008, at 12:40, Felix Gnass wrote:

> Daniel Dekany wrote:
>> Thursday, May 22, 2008, 11:52:06 AM, Attila Szegedi wrote:
>>
>>
>>> On 2008.05.22., at 1:14, Jonathan Revusky wrote:
>>>> BUt seriously, this really has me thinking that, unless we're in a
>>>> competition to have the funkiest dynamic language around (perhaps  
>>>> kind
>>>> of like trying to be more catholic than the pope) we should take a
>>>> step back from this and just think about how desirable it is  
>>>> really to
>>>> have these semantics. I would tend to think that the Guido way,  
>>>> how it
>>>> works in python, is the best, most straightforward option, and we
>>>> should go that way. There is the matter of this having worked (or  
>>>> kind
>>>> of) in 2.3. But I can't believe we would break many templates by
>>>> disallowing it. It's probably fairly rare that people rely on this.
>>>>
>>> I don't know. I guess I'm okay with that too, it's just that I  
>>> figured
>>> out that this is something that can be make to work fairly easily,  
>>> and
>>> all it does is adds to the expressive power of the language in a
>>> nonintrusive manner (if you don't use it, you don't see it). If,
>>> however others consider this to be too "funky", well, let's go for  
>>> the
>>> fail-always... I wonder what's Daniel's opinion...
>>>
>>
>> I can't tell a use-cases for this right now...
>> ...

> Another use-case is the option-tag where the label defaults to the
> value. This allows you to write
> <@form.option "foo" /> as well as <@form.option "foo" "42" />.
>
> All the examples above could also be implemented when there was  
> support
> for _optional_ parameters _without_ a default value or a "null"  
> default.
> I'm thinking of something like <#macro label for field=null> or  
> better:
> <#macro label for field!> due to FreeMarker's null-unawareness.
>
> In Python you can use the "None" object as default so there's no need
> for constructs like foo(x, y=x).
>
> Currently the only possibility in FreeMarker is to abuse empty strings
> and use the ?has_content built-in, which is quite an ugly hack, as it
> means that users can't pass empty strings to the macro (well they  
> could
> but it would make no sense) because this would be equivalent to simply
> not specifying the parameter at all.
>
> I think these are two valid use-cases and it would be really nice if
> FreeMarker would officially support this undocumented language  
> feature.
>
> -Felix
>


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.

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).

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?


-- Tim


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