Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: st: rclass AND sclass AND eclass
Sergiy Radyakin <email@example.com>
Re: st: rclass AND sclass AND eclass
Wed, 30 Nov 2011 11:20:39 -0500
Dear Daniel, Maarten and Nick, thank you very much for sharing your thoughts
on this. One thing I must add, is that (IMHO) for many users -return
list- is the
main hint on what results are left after the program (not documentation, and
even more surely not looking into the source code). And inconsistent returns
in interactive mode and batch mode can be a source of mistakes. Other than
that there is no problem now, that the reason for such a behavior is clear.
Thank you, Sergiy Radyakin
On Wed, Nov 30, 2011 at 4:19 AM, Nick Cox <firstname.lastname@example.org> wrote:
> I agree with Maarten. I don't think anything Sergiy says is incorrect,
> but his proposals would just make both syntax and documentation more
> complicated with no apparent real gain. The pluses and minuses of
> results remaining in memory versus being overwritten by others are
> delicate and it's a rare programmer who has never been bitten by this.
> At the same time, it is usually easy to diagnose. And any intention to
> make the documentation the truth, the whole truth and nothing but the
> truth would actually make learning and using Stata more difficult for
> almost all users, even including the majority of programmers.
> I also agree with many of Daniel's comments, but I don't think the
> distinctions r-class, e-class, etc. have anything to do with the C
> language. They are pure Stata.
> On Wed, Nov 30, 2011 at 8:36 AM, Maarten Buis <email@example.com> wrote:
>> On Wed, Nov 30, 2011 at 1:25 AM, Sergiy Radyakin wrote:
>>> the documentation for Stata declares that each program can be either
>>> rclass, or sclass, or eclass (or nclass). See -help program-.
>>> In many cases this is indeed true, but as the programs become ever
>>> more complicated, this strict correspondence breaks down at
>>> some level. Here is a trivial demonstration:
>>> program foobar
>>> program foo, rclass
>>> return local result = 1
>>> program bar, sclass
>>> sreturn local result = 2
>>> Here -foobar- is declared as nclass, and its subroutines are declared
>>> as rclass and sclass. A casual observer might inspect only the
>>> -foobar- main routine, and come to the conclusion that the r- and
>>> s-results are safe and not damaged by the command. While in fact
>>> the program makes use of both r-results and s-results, and hence this
>>> must be clearly documented.
>> I see your point, but it has never bothered me nor does it bother me
>> now. I guess I am just used to the fact that especially r-class
>> results won't survive any subsequent commands, and as a consequence I
>> have never been bitten by this. The trick is not to try to be smart,
>> and just store the results you need later on, in a scalar, matrix, or
>> macro as soon as it is created rather than rely on them surviving any
>> subsequent commands. I find that this creates easier to understand and
>> debug code, as this way the content of the scalar, matrix or macro is
>> explicitly assigned at the point it was created. Than again, I
>> probably find that easier/clearer because I am used to it.
>> One way to achieve what you want is to make the returned results local
>> rather than global. However, I guess that will break too many existing
>> programs to be feasible now.
>> -- Maarten
>> Maarten L. Buis
>> Institut fuer Soziologie
>> Universitaet Tuebingen
>> Wilhelmstrasse 36
>> 72074 Tuebingen
>> * For searches and help try:
>> * http://www.stata.com/help.cgi?search
>> * http://www.stata.com/support/statalist/faq
>> * http://www.ats.ucla.edu/stat/stata/
> * For searches and help try:
> * http://www.stata.com/help.cgi?search
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
* For searches and help try: