On Sun, 16 Dec 2012 16:02:25 GMT, Robert wrote:

After developing a bit with vibe, I got the impression that diet files are no stand alone entities. They don't present some interface or a method signature so that it is obvious how to use them. So in my understanding they are meant to be reused together with their instantiating context. So the diet template basically is a part of the struct/class/function that instantiates it and you reuse it by instantiating that struct/class and set some parameters for example (or call the method with different parameters).

What I don't understand is, if there is this strong coupling between the diet template and the instantiating context, why bother passing template parameters and not making the template a mixin with access to everything the class/struct/function has access to?

The idea was to keep the template as hygienic as possible regarding access to outer symbols and make it behave similar to a separate module. However, since internally it is nothing more than a string mixin (and some setup), it would be no technical problem to offer that as an alternative. It could look something like this:

mixin(compileDietTemplate!("template-file.dt", "res.bodyWriter"));

or this:

auto stream__ = res.bodyWriter;
mixin(compileDietTemplate!("template-file.dt"));

So the variable that holds the output stream would somehow need to be passed to the mixin generator.

To me it seems to be unnecessary cumbersome to pass every little needed variable to the diet template and to import many things twice (once in the D source code and once in the diet template) for apparently no good reason. Because the template depends on the instantiating context already and also in a non clear way if you just look at the diet code.

What are the reasons for the current behaviour? Am I using things the wrong way?

The reason is similar to why this is done in normal modules (i.e. when you import some module it will not inherit symbols from this importer's scope); It could mean that you accidentially pass wrong things to the template and it means that now not only the explicitly passed symbols are "magically existent" inside of the template, but also all symbols that are available because of imports or other declarations inside of the source file. Especially in multi-developer scenarious this could lead to unclean and strongly coupled code. The current way at least provides one place that documents which variables are actually usable by the template.

Is my view that a diet template is basically a part of the instantiating context, that just happens to be in a different file, correct?
And if so, could we make it behave more like that? I would volunteer for this.

Definitely in most cases templates are only used in a single place, so in this sense it is part of that context. And although I would like to keep the interface as strict/clean as possible, such a mixin seems to enable a number of fair use cases. If you want, you can give it a shot. But since implementing this is only a matter of seconds and because I wanted to choose a better name for parseDietFile anyway, I wouldn't really mind doing it, too (I'd try to do it ASAP).