I totally agree that this is a working solution, that I don't debate.
I just don't like it that much.
On the second thought, if you staring caring about the program
versions, the data base of what program depends on what version of
another program will quickly be getting quite huge. So it is better be
left to the programmers who really have crucial dependencies between
elements of a program. So mine is an overshoot, and yours is more
relevant indeed.
Stas
On Wed, 29 Sep 2004 17:02:41 +0100, Nick Cox <[email protected]> wrote:
> I am sorry that you find this inelegant. It was offered
> as a practical solution, not as an exemplar of elegance.
>
> For my part, I can't support your urging StataCorp to
> introduce new commands which aren't needed. There
> are many things more needed and more desired.
>
> Nick
> [email protected]
>
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of
> > Stas Kolenikov
> > Sent: 29 September 2004 16:23
> > To: [email protected]
> > Subject: Re: st: further version questions
> >
> >
> > 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/
