[stringtemplate-interest] sequences and unique numbers

[Sam Barnett-Cormack]

Having another think about this, while working with ST a bit more, I see 
that the real problem isn't any quasi-religious dedication to avoiding 
side effects or anything like that. It's 
order-of-evaluation-independence. It's a harder question to solve.

I suppose we'd have to say that there was no repeatability guarantee as 
to which template instance would get which value, but it certainly 
couldn't be some as pseudo-procedural as my suggestion, which only works 
if the attribute invocations are done top-to-bottom. As such, special 
syntactic sugar on the template parameter declaration makes more sense 
than my suggestion. However, I see a concern similar to scopes in ANTLR.

Say I have 4 templates that represent entities that will have unique 
IDs: A, B, C and D. In a simple case, it is necessary for them to be 
mutually unique. Now, as long as A, B, C and D are never nested in any 
way, it's fine. However, if an A may contain one or more B, C, or D, and 
B may contain C or D, we have to be very clear as to what happens, 
especially if any of B, C and D can also occur free-standing. Any 
occurence of the ID attribute in A *itself* must be consistent, and the 
occurences underneath must be distinct from those in A itself.

But sometimes they may not want to be mutually unique, or an instance of 
B will need to make use of the ID attribute from A, if set, *and* its own.

Now, I can see how all of this could be done with the curernt system, 
from your initial description, but I can see that they'll need clear 
documentation and some best practices. I can see a value in the 
recommended course being setting of formal parameters to a default 
value, which does some sort of immediate-invoke of a property of an 
object that evolves its own state. That's great. However, there's an 
issue of parameter scoping - doing this recursively could cause problems 
unless the parameters have clearer scoping. As I understand it, and I 
may be wrong, if a template has a formal parameter, and the invoking 
template can "see" an attribute of that name, then it's implicitly 
passed. Is this still the case if the parameters has a default? Say, 
templaet A has an attribute, no default, call att1, and template B has a 
formal parameter *with* default also called att1. A invokes B without 
explicitly setting att1. What value of att1 does B see? Should it be 
possible to define B so that you choose whether to implicitly receive a 
parameter or not?

My current gut feeling is towards expanding the specification of ST to 
change the way templates are defined to allow more customisation - 
scoping or parameters, defaults, etc. Your uniq suggestion is okay, as 
long as we say that ST assumes no side effects without actually acting 
on that assumption. It may, in futre, matter. The assumption of no side 
effects may in fact allow optimisations as we consider semi-compiled 
templates, as it does in functional language compilers. To guard against 
this, I would suggest being able to mark attributes/attribute properties 
that will/may cause side effects, and restrict where they can be used. 
In the java case, the classes may implement a marker interface, or if 
you want to have some flexibility (and restrict it to Java 5 onwards) a 
runtime-visible annotation - the advantage being that that can be 
applied to getters as well as classes. One place they might be permitted 
is in default declarations, but not in template bodies.

Well, that's just a few thoughts.

-- 
Sam Barnett-Cormack