Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
References: <4C93A430.1020103@morningstar2.co.uk>
            <20100917180303.GA7348@oberdiek.my-fqdn.de>
            <19603.49961.484432.456512@morse.mittelbach-online.de>
            <20100918103114.GB25082@oberdiek.my-fqdn.de>
Content-Transfer-Encoding: 8bit
Message-ID:  <4CD7B98D-31F9-49FA-BDCD-91D6E7F03114@yahoo.de>
Date:         Sat, 18 Sep 2010 13:04:13 +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: Philipp Stephani <st_philipp@YAHOO.DE>
Subject: Re: Option parsing bug or 'feature'?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <20100918103114.GB25082@oberdiek.my-fqdn.de>
Precedence: list
Status: R

Am 18.09.2010 um 12:31 schrieb Heiko Oberdiek:

> My recommendation for package authors that use key value interfaces
> is to provide a \<package>setup command for setting the options
> and getting rid of the option limitations of LaTeX2e.
> 
> Also setting options in \usepackage makes problems with option
> clashes more likely, especially if the package is already loaded
> without options.
> 
> Another problem is that the option share the same namespace.
> Global options can trigger wanted and unwanted actions in
> different packages, that knows the same option. That's even
> more problematic for key value options, where the packages
> interprete the same keys, but the values with different syntax.

I agree.  I use the following policy for package options, which I believe is defensive enough:

- Avoid options whenever possible.
- If an option is required (e.g. if a package loads another package conditionally), always process it locally using \ProcessLocalKeyvalOptions (kvoptions) or \ProcessKeysPackageOption (l3keys2e).
- Never process global options except "standard" ones like "draft".