I am not clear on precisely what you are suggesting but my prior
probability of StataCorp letting you doing anything
of the kind here really is zero.
Once you start overriding the inbuilt priorities of
Stata the scope for all kinds of horrible bugs and gotchas
increases dramatically. The problem is not what you
(think) are doing; it is the hidden consequences.
As Stata's commands can be nested many times, these
are normally very much hidden from you.
That is not to say that users cannot be frustrated
on occasion by Stata's choices and that many smart
users can see a better way of doing certain things.
But the answer does not lie in messing with Stata's settings;
it's in exploiting Stata's extensibilitiy.
To put it personally, I have been using Stata almost
every work day for 16 years and have written several
hundred Stata programs and I know not to want to mess with
Stata in this way.
Nick
[email protected]
Sergiy Radyakin
> I just wanted to add to this discussion, that the problem would have
> been easily resolved if user-written commands had priority over
> built-in commands. Currently, the presence of "do.ado" in the ADOPATH
> makes no difference, and the built-in command gains control after "do
> dofile". Being able to override built-in commands similar to the way
> it is done with the external commands (stored in .ado files) would
> further increase flexibility of Stata: all older programs will receive
> new features simultaneously without any changes in their code (e.g.
> then I might override "save" command to log the filename and user's ID
> to track changes to files, or mirror backup copies, etc). I think this
> could be implemented by adding built-in identifier (say symbol *) to
> ADOPATH lines (note that * may not be a part of a filename in
> Windows), the user then can determine priorities on her own, by
> ordering the paths in ADOPATH.
>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/