How can I make a Stata module adding an option to an existing Stata command?

[Minch Park]

Hi, I am developing a new variance estimator of the fixed-effects estimator, and so I hope that it is possible for the users to add the option calculating my variance estimator to the xtreg command just by typing ssc install command name.

Fortunately, one of my colleagues let me know that we can add an option to an existing Stata command in a specific case.
Specifically, in my memory, the absorb option is now available with the xtreg command after we install another program.

So, I am wondering how I can make a Stata module adding an option to an existing Stata command.
Is it possible? If it is, then how can I connect my mata or ado files and the existing command?

[Jared Greathouse]

If this were my problem, I would copy the ado file of the command to a do file (let's say I wanna make another OLS command), I would copy reg to a new do file, add in my option, and then just use reg2 using that new option.


However, reg is property of Statacorp. If you look at the ado code for it, you'll find that much of it is obscured, wrapped in the private classes of Stata's native hardware.

What I do to write commands, I use a command called "adoedit" (user written). In your case, you'll just copy xtreg to a new place (i think) and then work with whatever options or features you have avaliable.


I could be wrong about some of this, so presumably daniel klein or someone else more experienced may correct me.

I don't think there's a Stata command which can add such an option, though. I think you'd need to code that yourself.

[Leonardo Guizzetti]

It is, in general, possible to write post-estimation commands that are designed to follow some initial estimation command. However, the limits of what you can and can’t do are very dependent on the details of what the prior command requires and what you need to do with it. In any case, this is an advanced topic that requires you to learn how to program such commands in Stata.

[daniel klein]

The initial question is vague regarding details of implementing the new variance estimator and the envisioned interplay with xtreg. The latter crucially depends on the former. If the new variance estimator requires intermediate results from xtreg, creating a modified copy of the respective ado-file(s) might be a good starting point. If the new variance estimator can be implemented in terms of returned results from xtreg, then there is no point in modifying a copy of xtreg. Either way, you should choose a different name for your command; it cannot be xtreg. Well, technically, it could but you don't want that. So, if your command is called something other than xtreg, why the trouble of implementing an additional option? That's more programming on your part and it is more typing on the user's part.

Assuming you can work with the results of xtreg, a post-estimation command, as suggested in #3, is one option. However, sometimes a wrapper is the better alternative. A basic layout might look like this:

program xtreg_fe_new_variance
    
    version 18
    
    syntax anything(everything) [aw fw pw] , FE [ * ]
    
    version `=_caller()' : xtreg `0'
    
    estimate new variance using results in e(b)
    
end

Compared to a (static) copy of xtreg, the wrapper approach benefits from any improvements (including bug fixes) that StataCorp might add to xtreg. Compared to the post-estimation approach, the wrapper approach often makes checking the requirements (here, that fe is specified) easier and generally allows you more control over what the caller types.

[Hong Il Yoo]

Minch Park: Perhaps you can consider something similar to what Ariel Gu and I did with the -vcemway- command, which generalises Stata's -vce(cluster varname)- option to multiple dimensions? Here's a link to the background paper in the Stata Journal: [Link]

[Minch Park]

Jared Greathouse Leonardo Guizzetti Thank you guys. Both editing the original ado program and writing a post-estimation command could be the solutions I think. If I eventually fail to find a way to add an option to the existing ado file, I will try to make a new ado file or a post-estimation command. Thank you again.

[Minch Park]

daniel klein Thank you Daniel, your comment includes very important point. I specifically wanted to add an option without any change of the command name. But, as you mentioned, that seems impossible. So, I think, it may be better to think about the approaches you guys recommended.

[Minch Park]

Hong Il Yoo That is very interesting idea! I browed the paper and realized that it could be better to make a command that can be combined with the original command like a prefix. In my understanding, the vecmway command is compatible with so many estimation commands, and it is suitable to write the vecmway command like a prefix. Unlike your command, my variance estimator is only for just one estimator, and so I am not sure whether the prefix-type command is better than the post-estimation-type command. However, your recommendation is really insightful and informative. I will consider more about your recommendation. Thank you.

[Nick Cox]

To add to points already made, especially by daniel klein, it's in general not at all a good idea to modify official commands, those distributed with Stata, even if they are entirely defined by accessible ado and Mata code. (And as said many are only partially defined in that way.)

Some reasons are

1. Suppose you modify an official command. Then you would need to repeat the modification each time there is a new release of Stata as StataCorp know nothing about your modification -- unless you communicate with StataCorp and persuade them that your modification should be made official, a different story.

2. Suppose you publicise and distribute the modified command to others. Now others have the same problem as in #1 -- and more problems too if they forget what is whose, and say bother StataCorp unfairly if they get confused about your addition, etc., or worse of all end up messed up if you leave Stataland, become too busy to support people using your code, etc.

3. Most people thinking like this have only good intentions, but Stata commands often interact with other commands, you might make a change you think is benign but which turns out to break the command, and so forth.

For these reasons I would never modify any official command, even quietly and privately on my own machine(s), and I would never download any command with the same name as an official command.

No, the recommended approach is to give your command a different name. How easy it is to write a wrapper command or a post-estimation command I have no idea in this case, but I fear it is much trickier than you're hoping.

[Minch Park]

Nick Cox That is very persuasive. Considering all recommendations above, I think, it is the best option to write a post-estimation command. Thank you so much.