[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: RE: RE: RE: RE: RE: Referring to a varname, leading to errors
Quite right. I did not intend to suggest that varname abbreviations couldn't
burn you accidentally. Quite the opposite. Indeed, particularly because I
never use, and hence do not rely on, varname abbreviations, I would
certainly be in favour of a -set-able option to disable them. My "in favour"
response to Nick's straw poll, however, comes with the qualification that I
don't plan to picket StataCorp's College Station office (campus for
semi-reformed academics?) if I don't get it. :-) <--- note: smiley face
means I'm joking
> -----Original Message-----
> From: Joly.Patrick@ic.gc.ca [SMTP:Joly.Patrick@ic.gc.ca]
> Sent: Tuesday, February 11, 2003 4:13 PM
> To: email@example.com
> Subject: st: RE: RE: RE: RE: Referring to a varname, leading to
> Nick wrote
> > But let's pose a question to Stata Corp and one to users.
> > 1. Stata Corp
> > =============
> > Suppose a user like Glen doesn't want to be bitten
> > ever by this. Imagine that such users can
> > . set literalvarnames on
> > meaning
> > "Listen here, Stata: you are to behave, given my
> > input, as if you never allowed abbreviated variable names."
> ... something akin to pragmatic modules in Perl, i.e. a way to instruct
> Stata how we'd like it to behave. Even Stata's version control facilities
> can be viewed as such (right?), so perhaps it might not be that difficult
> > How easy would that be? Would there be side-effects?
> > Well written programs that Glen uses, consciously
> > or not, should all make use of temporary variables,
> > but in practice there may be exceptions.
> > In practice, perhaps, the issue is Command window input PLUS .do
> > files.
> > 2. Users
> > ========
> > Do you want what Glen wants? Not disallowing all
> > variable name abbreviations, which I guess will
> > never happen, but being able to set this for yourself
> > to avoid what Glen describes.
> > Nick
> > firstname.lastname@example.org
> To which Lee Sieswerda replied
> > I, for one, never use varname abbreviations. Perhaps in some deep
> > recess of my psyche I believe in Murphy's Law and don't want to run
> > into Glen's problem inadvertantly.
> Abbreviations can hurt you even if you don't ever use them, such as
> i) dropping a variable you never intended to drop; or
> ii) inadvertently modifying the wrong variable
> For e.g., at some point in time your data contains variables _foo_ and
> _foobar_. You no longer need _foo_ so you -drop- it. Later, (wrongly)
> believing _foo_ is still defined, you -replace foo = ...- but it modifies
> -foobar- instead since Stata finds no ambiguity in the string literal
> You might never notice this blunder. Dealing with large datasets at
> with hundred of variables possessing names that differ by only a character
> or two, this can have unfortunate consequences. I almost never use
> abbreviations myself either and typically, when I want to modify _foo_, it
> is _foo_ I want to change and certainly *not* _foobar_.
> Granted, if nothing can be done to let users specify Stata's behaviour via
> pragmatic command, some cost-benefit analysis must be made to weigh user
> convenience vs. safety-features. And if that's the case, then I can live
> with it. But if the sole explanation for this behaviour is rooted in
> history (of Stata's development that is), then it becomes increasingly
> difficult to buy into the cost-benefit justification. To have the option
> turning off all abbreviations would be a monumental safety improvement
> Patrick Joly
> * 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/
* For searches and help try: