Re: [Templates] TT in callback

> On Thu, 2005-01-06 at 11:08 +0000, Andy Wardley wrote:

Perrin Harkins wrote:
> On Thu, 2005-01-06 at 11:08 +0000, Andy Wardley wrote:
> 
>>I must admit it worries me slightly that I come down 90% in favour of one
>>approach and you're swung 99.9% the other way.  Assuming the efficiency 
>>problem goes away in TT3, is your position that non-localising is the 
>>correct behaviour by default, or rather that the name of the directive 
>>"INCLUDE" suggests that the template is processed inline and thus the 
>>user is expecting the variables to be imported, regardless of whether 
>>this is the more useful behaviour or not?
> 
> 
> It's both of those.  I think that:
> - The current version of INCLUDE can be a significant performance hit
> for templates with lots of INCLUDE calls (vs. PROCESS).
> - It's not technically possible for localising (the UK spelling! my
> e-mail client is freaking out!) to be as fast as not localising in TT3.
> - Most people don't even know that INCLUDE has this behavior and might
> not want it if they did know.  This is what I draw from the surprise
> that people always express when this comes up on the list.
> - The word "INCLUDE" clearly implies it is the normal way to call other
> templates.
> - The word "INCLUDE" makes it sound like templates are being inlined.

When I first started using TT this is what I inferred from the word. As 
Larry says it was too simliar to the C\C++ include and I made the 
assumption and we all know what they say about "assume". It was only 
after spotting the entry in the Badger book P144 that I saw my mistake.

> Although people on the list talk about setting variables inside of
> templates, I think this is quite rare in normal usage.  The only thing I
> see people do frequently is pass variables in macro and include calls,
> which is why I like the suggestion Mark Mills just made: localise those
> variables, and leave everything else alone.  I also favo(u)r having a
> localising version with another name, like LINCLUDE or SAFE_INCLUDE.
> PROCESS vs. INCLUDE only makes sense to someone who knows the internals.

Would you then alias INCLUDE to PROCESS?

You know a lot more about the work involved than me but for backwards 
compatibility but would it not be easier to make INCLUDE_FAST an alias 
to PROCESS. My reasoning is probably a bit mad but here goes.

Most people that read the next version of the badger or the docs will 
see both INCLUDE and INCLUDE_FAST and of course as soon as they see the 
word FAST they are going to want to know more and spot the distinction 
between the two. Its purely psychological but then I think that INCLUDE 
is fine once you have found the bits in the badger book that describe 
what it does.

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates