[SOLVED] Should I be using tempnames in Stata ado packages, or will using local macros be sufficient to avoid namespace collisions?

Should I be using tempnames in Stata ado packages, or will using local macros be sufficient to avoid namespace collisions?

Assuming that the user will only interface with a Stata .ado package program through any data supplied, and via command syntax (i.e. with options, etc.), do I gain any protection around namespace collisions by using MySecondGreatProgram instead of MyFirstGreatProgram (or does local imply what tempname does)?

program define MyFirstGreatProgram, rclass sort
  syntax varlist, this(integer 1) that(integer 1) [other(integer 1)]
  local MyVar = this + that
  [Really useful code involving `MyVar']
  end

Alternately…

program define MySecondGreatProgram, rclass sort
  syntax varlist, this(integer 1) that(integer 1) [other(integer 1)]
  tempname MyVar
  local `MyVar' = this + that
  [Really useful code involving `MyVar']
  end

Additional benefits of preferring the second to the first (or vice versa) welcome, but I am particularly interested in namespace gotchas.

Solution

I can't imagine any namespace problems with form 1 or any advantages of form 2, unless you introduce code errors of your own.

In essence, local declares macros that will be visible only within the program in which they are defined. You can define them or re-define them or remove them by blanking them out, but nothing is visible outside that program unless you export the value of the local macro.