[stringtemplate-interest] ST multi-valued attributes modification inconsistency

[Zenaan Harkness]

By my reading of StringTemplate.java, setAttribute has two ways
that multi-valued attributes can be stored:

1) Within the Collection as passed in by a user.

2) Within a Collection instantiated by ST itself.

This seems conceptually inconsistent.

I could pass in some collection, eg.
myst.setAttribute("importantStuff",myUpdatingList)

and then later on during my ST building phase, I'm adding to
myUpdatingList.

Of course, then I forget and go and add an extra item or list etc
to my ST instance, and now the value stored by ST is no longer my
myUpdatingList but is an STAttributeList (ST managed list).

I then add another value(s) to myUdatingList, which value(s) are
not output by myst.toString() because myUpdatingList is no longer
stored by ST!

I think this is conceptually horrible, and in all cases, ST should
create its own "lightweight as possible" containers to store
stuff (at least, when there's more than one value - the
implementation can of course be performant, it's the consistency
of the conceptual model I'm talking about). That should probably
be the default.

Alternatively, to maximise performance, there could be a "use my
container only" version of setAttribute, which could perhaps be
done by way of subclassing StringTemplate.java.

Yes, the example above can be considered a bug in my code, but why
have the potential landmine when it's unnecessary.

If there's an explicit
myst.setAttributeStorageMode([STManaged,UserManaged]) method, then
it is up to the user to decide how to behave. As it is, the
current behaviour is documented somewhat, but in actual behaviour
is implicit. The ST constructor is another place where this mode
of operation could be set.

Thoughts?
Zen

-- 
Free Australia - www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.