Well certainly so, but you'd agree this is not a very elegant
solution. It's like saying, "Why would one need return values r() or
e() or s() if you can just return the results in $S_1, $S_2, etc.?"
Stas
On Wed, 29 Sep 2004 13:54:13 +0100, Nick Cox <[email protected]> wrote:
> I am not clear that this need depend on StataCorp
> introducing new commands.
>
> Any user-programmer could set up a system like
> this using globals and locals.
>
> In one main program a programmer could set
>
> global frog_version 42
>
> and in called programs could set
>
> local frog_version 42
> if `frog_version' != $frog_version {
> di as err "frog: using a mix of old and new versions"
> exit 498
> }
>
> and so on.
>
> Nick
> [email protected]
>
> Stas Kolenikov
>
>
>
> > > But that would gain you nothing, really. -mvis- is just part
> > > of a package and the whole package would need
> > > to be scanned in a bid to remove Stata 8 features,
> > > which would I guess require considerable programming
> > > expertise.
> >
> > Can I pick from here on my own thing? Each time I update Sophia
> > Rabe-Heskteh's -gllamm-, some of the modules come out to be outdated,
> > which I only find out when it crashes. (I know -net install- should
> > work perfectly, but I found once that one of the older pieces was
> > sitting in a directory of -adopath- prior to others, and thus caused
> > problems until I deleted it from there). So for all five or six
> > ado-files I have to type -which gllamm-, -which gllapred-, etc., and
> > compare to the current versions on -gllamm- website.
> >
> > So my suggestion/wish/grumble to Stata Corp. is to set up something
> > like -userversion- version control system, so that the internal
> > version of the module is specified not through
> >
> > *! v.3.1 NJC 29 September 2004
> >
> > in the first line of the ado-file, but as a
> >
> > *! NJC 29 September 2004
> > program define blahblah, eclass
> > version 8.2
> > userversion 3.1
> > userneed blahblah_ll 1.11
> > ...
> > end
> >
> > Then whenever -blahblah- calls -blahblah_ll-, the -userversion- of the
> > latter is checked against 1.11 and should be no less than that. Or an
> > option like
> >
> > userneed blahblah_ll 1.11, strict
> >
> > can be provided for the lazy programmers like me who do not want to
> > program their routines to be backward compatible, so that the current
> > version of -blahblah- will only accept -userversion 1.11- to work
> > with.
> >
> > Is this too much to ask for? Does anybody else in the stataworld need
> > this except me?
>
> *
> * 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/
>
--
Stas Kolenikov
http://stas.kolenikov.name
*
* 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/
