"Phillip J. Eby" wrote:
Let me throw out a counter-proposal, however. Suppose that the _()/_.namespace() functions were changed to return writable namespace objects?
I confess to having already done this for my own use since v1.10.2 Your point about untrusted-call safety is well-taken, and now that I think about it I have an alternate proposal :-) If only lexically enclosed code is allowed to alter Let variables, why even bother with non-writable variables? Allow Set to operate on the enclosing Let namespace, without limit. Heck, allow it to introduce new names, if it wants to. Thus: <dtml-let x="1+1" firstname=" 'fred' "> ... <dtml-set firstname=" 'mary' " weight="135"> ... <dtml-set qty="5" price="1.50" extprice="qty * price"> ... </dtml-let> Note that this makes nested Let superfluous, and <dtml-let ...> is essentially shorthand for <dtml-let><dtml-set ...> Now if every DTML object had a default empty local namespace, we could do away with Let entirely and just use Set.
Then, your example could be written as:
<dtml-let x="1+1" person="_(firstname='fred',weight=180)"> <dtml-var x>, <dtml-var "person.firstname">, <dtml-var "person.weight"> <dtml-call "person.set('weight',185)"> <dtml-var weight>
This diverges here, since 'weight' is *only* an attribute of 'person', not a full member of the namespace. Of course, to complete the insanity of my new proposal, we could keep the colon notation as a compact way of defining/altering this sort of sub-namespace 8->
Last, but not least, I should probably note that my enthusiasm at the simplicity and elegance of these solutions from a programming standpoint is matched only by my misgivings about how much harder they may be to teach someone how to use than local/set. But I guess I'll withhold judgment on that until I've had to do it. :)
Ditto. Cheers, Evan @ 4-am