Sender: |
|
Date: |
Wed, 21 Sep 2011 20:25:27 +0100 |
Reply-To: |
|
Message-ID: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
7bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=ISO-8859-1 |
From: |
|
Parts/Attachments: |
|
|
On 21/09/2011 19:57, Frank Mittelbach wrote:
> Am 20.09.2011 05:57, schrieb Will Robertson:
>> On 20/09/2011, at 4:13 AM, Frank Mittelbach wrote:
>>
>>> I think bottom line we don't really need them any more these days.
>>> The only reason why I would keep them is that for fast access to
>>> variables when experimenting/developing (without needing to declare
>>> something first), but for proper packages it is far better come up
>>> with your own private scratch names.
>>
>> I agree with this, but I don't think we should remove anything that's
>> been around for a while now. I suggest removing the just-added clist
>> scratch variables and keeping what remains as they are -- but not
>> adding any others.
>
> my takeaway is actually different. I would suggest to keep the tmp
> variables and provide for each datatype exactly two/four default ones
> (also for the new types)
>
> \l_tmpa_int
> \l_tmpb_int
> \g_tmpa_int
> \g_tmpb_int
>
> In the general documentation we might explain the issue and risks and
> that we suggest to carefully consider in packages for general use to
> define "private" scratch variables instead, and that those here here for
> convenience as some people prefer this style of programming.
I'm with Frank on this: there is not really a problem with providing a
small number of scratch variables. So the only question is how many. At
the moment, we've got 'mainly tow, a and b'. Seems reasonable to be
going on with.
--
Joseph Wright
|
|
|