Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100]) by h1439878.stratoserver.net (8.14.2/8.14.2/Debian-2build1) with SMTP id q4QM9udL013641 for ; Sun, 27 May 2012 00:09:58 +0200 Received: (qmail 31248 invoked by alias); 26 May 2012 22:09:51 -0000 Delivered-To: GMX delivery to rainer.schoepf@gmx.net Received: (qmail invoked by alias); 26 May 2012 22:09:51 -0000 Received: from relay.uni-heidelberg.de (EHLO relay.uni-heidelberg.de) [129.206.100.212] by mx0.gmx.net (mx048) with SMTP; 27 May 2012 00:09:51 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id q4QM7AL5005179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 May 2012 00:07:11 +0200 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id q4QM17IE002170; Sun, 27 May 2012 00:07:10 +0200 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 16.0) with spool id 1988134 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sun, 27 May 2012 00:07:10 +0200 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id q4QM7Aro002656 for ; Sun, 27 May 2012 00:07:10 +0200 Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id q4QM6DG8000668 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Sun, 27 May 2012 00:07:09 +0200 Received: by vcbf13 with SMTP id f13so1340041vcb.22 for ; Sat, 26 May 2012 15:06:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.174.99 with SMTP id br3mr3151112vdc.85.1338069973263; Sat, 26 May 2012 15:06:13 -0700 (PDT) Received: by 10.220.141.131 with HTTP; Sat, 26 May 2012 15:06:13 -0700 (PDT) References: <4FC13326.1060904@morningstar2.co.uk> Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Whitelist: Message-ID: Date: Sun, 27 May 2012 00:06:13 +0200 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Bruno Le Floch Subject: Re: Should l3keys provide a key .initial:n? To: LATEX-L@listserv.uni-heidelberg.de In-Reply-To: <4FC13326.1060904@morningstar2.co.uk> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-GMX-Antispam: 0 (BackTrace mail analyze); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnGL2vqOgpaBYL16oitsMrgDt/NQNpSCZFFjDOy 97xb7Zpf+wZnd5ZXNcvLDXR3Wg3wRjdQbwEMh8=V1; X-Resent-By: Forwarder X-Resent-For: rainer.schoepf@gmx.net X-Resent-To: rainer@rainer-schoepf.de Status: R X-Status: X-Keywords: X-UID: 7057 On 5/26/12, Joseph Wright wrote: > On 26/05/2012 16:12, Marco Daniel wrote: >> Hello, >> >> Today I noticed that there is no key .initial:n. This question popped up >> during writing a small package. Whatever at the moment you have the >> following possibilities to set a key-value-syntax with an initial value: >> ======================================================================= >> %First approach: >> >> \keys_define:nn { module } >> { >> myoption .int_set:N = \l_modul_myoption_int >> } >> \keys_set:nn { module } >> { >> myoption = 2 >> } >> \ProcessKeysOptions { module } >> >> ======================================================================= >> Second approach >> >> \keys_define:nn { module } >> { >> myoption .int_set:N = \l_modul_myoption_int , >> myoption .default:n = 2 >> } >> \keys_set:nn { module } { myoption } >> \ProcessKeysOptions { module } >> >> ======================================================================= > > Note that this are not equivalent when you consider the behaviour later > on. In the second case, giving "myoption" is the same as "myoption = 2", > but in the first case the two are distinct. > >> I suggest to define a new key .initial:n so that we have a third >> approach: >> >> Second approach >> >> \keys_define:nn { module } >> { >> myoption .int_set:N = \l_modul_myoption_int , >> myoption .initial:n = 2 >> } >> \ProcessKeysOptions { module } >> >> ======================================================================= > > At one point we did have this. Checking back through the archive, I > removed it as it did not seem to add anything to the two-stage process. > However, that was not a 'strong' objection: I was simply trying to keep > the number of properties down as far as possible. If this looks like a > useful addition I've no problem adding it back in: anyone else have a view? > -- > Joseph Wright > I'm no keys expert, but couldn't \int_set:Nn \l_modul_myoption_int { 2 } do the job, at least in this case? Cheers, Bruno