Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Oddity with -bootstrap- handling an option on command input

From   [email protected] (Vince Wiggins, StataCorp)
To   [email protected]
Subject   Re: st: Oddity with -bootstrap- handling an option on command input
Date   Mon, 19 Sep 2011 22:43:30 -0500

Mike Lacy <[email protected]> is writing his own command that
he then bootstraps using the -bootstrap- prefix.  He reports that
-bootstrap- will not pass the option -l()- through to his command.

> ...
> Is this a feature, i.e., are option names generally to be regarded
> as reserved words in relation to commands that accept a command
> name?  I would have thought that -bootstrap-'s own macros, and that
> of its input commands, would not share namespace.
> ...

Mike is right that -bootstrap- does not share option name spaces for its
own options and those of the command it is running.  There are,
however, two exceptions -- options -vce()- and -level()-.  These
options are supported by all official estimation commands.  

-bootstrap- needs to know about -vce()- because it may need to cluster
the draws if that is implied by the -vce()- option.

Regarding -level()- we found that too many people were mistakenly
specifying -level()- on the command itself instead of in the
-bootstrap- options, so -bootstrap- intercepts -level()- and does not
pass it through.  What is unfortunate is that -level()- is an option
that has been around a long time, and in days gone by we were
comfortable allowing it to be abbreviated -l()-.  (We would not to that
today; -lev()- would be about as far as we would go.)  Regardless, 
-bootstrap- steals all abbreviations from l() to level().

Mike might argue that we are being too parental, and he might even
convince me.  Even if he did, we would not want to change a behavior
that others may have come to rely on.

The documentation is silent on this and it shouldn't be.

-- Vince 
   [email protected]

*   For searches and help try:

© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index