Re: st: rclass AND sclass AND eclass

[Nick Cox <njcoxstata@gmail.com>]

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.

Nick

On Wed, Nov 30, 2011 at 8:36 AM, Maarten Buis <maartenlbuis@gmail.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
>>    foo
>>    bar
>> end
>>
>> program foo, rclass
>>  return local result = 1
>> end
>>
>> program bar, sclass
>>  sreturn local result = 2
>> end
>>
>> 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
> Germany
>
>
> http://www.maartenbuis.nl
> --------------------------
> *
> *   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/