Lines: 48
References: <1rb2vdciob67d$.dlg@nililand.de>           
            <4E5F75C0.8030105@morningstar2.co.uk>
            <fqvtzpmiulpq.dlg@nililand.de> <4E5FA851.3040504@morningstar2.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
User-Agent: 40tude_Dialog/2.0.15.41de
Message-ID:  <ryxwvn1cec4o.dlg@nililand.de>
Date:         Thu, 1 Sep 2011 18:10:03 +0200
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: Ulrike Fischer <news3@NILILAND.DE>
Subject: Re: Internal equivalent of \providecommand?
To: LATEX-L@listserv.uni-heidelberg.de
Precedence: list
Status: R

Am Thu, 1 Sep 2011 16:44:17 +0100 schrieb Joseph Wright:

> On 01/09/2011 13:53, Ulrike Fischer wrote:
>> Well my command (it is more a variable so \tl_set would perhaps be
>> more correct) must exist and that's why I'm using \providecommand:
>> To make sure *that* is exists. I'm not relying on a "might exist"
>> command but try to ensure that it is a "does exist" command.
>> 
>> The problem is that it must exist in various encoding definitions
>> files for fontenc, in the sty (chessfss) and that its "value" can be
>> set/changed by the user -- which means that I have no control over
>> the location where the default value should be set. I have to set it
>> in various places in such a way that it doesn't overwrite user
>> settings.
> 
> That's broadly what I mean by 'LaTeX2e issues': having a value which is
> used directly at a user level, and in various files, is not good.
> 
> You don't say if the value might alter again after you've
> \providecommand'd it. If not, then I'd be tempted to go with something like
> 
>   \tl_new:N \l_<internal-thing>_tl
>   \cs_if_exist:NTF \<thing>
>     { \tl_set_eq:NN \l_<internal-thing>_tl \<thing> }
>     { \tl_set:Nn \l_<internal-thing>_tl { <default> } }
> 
> On the other hand, if this variable in question has to be user-setable
> at any point, then you can't use an internal value and have to stick to
> a manual '\providecommand' approach.
> 
> (I'm assuming that the variable in question is one that is already
> required by LaTeX2e constructs, and so 'simply do things differently' is
> not an option.)

The variable in question is my own command and I can do with it what
I want. That is not the problem. 

But as I now started to rewrite chessfss with expl3 I'm trying to
use clean code, to exploit its features and to avoid unnessary hacks
and compromisses. 

And after thinking more about it: I think the cleanest solution is
to export the commands in question in a .sty and to use
\RequirePackage to include them in the various files. Then they are
set exactly once and are only in one place.  

-- 
Ulrike Fischer