Lars, Andrew:
I was thinking the namespace idea was something helpful as well, but when trying to write a reply that indicated so, I seemed to stall out as to why it would be a good idea.
The truth is, namespaces will not solve the problem, which is one that must be solved on a per page basis, taking into consideration the different variables being used.
Example: you write a query that has several column names that are the same. Obviously they have distinct meanings in the context of the query, so you use 'as' to rename the column. This is the exact problem we have, fortunately it is solved at the sql level in a self documenting format. The fact that higher up on the page, you had a similarly named variable doesn't remove the fact that the variables have distinct meanings, and should have distinct names. Putting the variable into a fixed namespace doesn't shed much light on the meaning of a variable, but renaming it would.
In ad_page_contract, it would be great to have an aliasing mechanism similar to those used in (pl/)sql, but the whole point of db_* procs is to operate in the same namespace, and hopefully the same level. Creating separate namespaces would only foster confusion. Why should variables be named based upon where they came from (query::, property::)? They should be named based on their meaning and use on that page.
