LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Tue, 30 Sep 2014 19:00:52 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <[log in to unmask]> (Joseph Wright's message of "Mon, 29 Sep 2014 22:36:31 +0100")
Content-Type: text/plain; charset=utf-8
From: Denis Bitouzé <[log in to unmask]>
Parts/Attachments: text/plain (85 lines)
Le 29/09/14 à 23h36, Joseph Wright
<[log in to unmask]>
a écrit :

> Sean has pointed to a similarity to dealing with mandatory arguments at
> a design level. This request seems a little different as l3keys isn't
> meant to be targeting that area. However, there is clearly overlap.

OK.

> At present, key properties mainly apply to individual keys in a 'stand
> alone' sense. This request is different as it's actually about an entire
> set of keys.

No, maybe I was unclear: my question concerned the "requireness" of
a single (or maybe several but treated separately) key property.

> To me, that seems a bit odd: it's pretty rare that buried inside a set
> of optional settings is one or more mandatory ones. There is also the
> question of what 'required' might mean, as
>
>     key = \empty
>
> or similar might well be equally invalid in the real use case but would
> presumably pass such a test.

In the use case I have in mind, `key' would be required and expect an
integer. Would it be missing, an error message would be emitted; would
its value be anything but an integer, an(other) error message would be
emitted.

> What I think we need before we can really comment is some solid proposed
> use cases, showing why the property is needed as opposed to other
> approaches as you outline.

Here is an outline of my use case. I'm working on a class for
a quarterly mathematical journal and I'd like to provide an \issuesetup
document command that lets the secretary specify, for each issue, at
least the (mandatory) number. The issue's month and year are computed
from the number but I'd like to let them be (optionally) specified if,
for any reason, a given issue is not published at time.

OK, this \issuesetup command could (and I started like this) be designed
to have a mandatory argument for the number and an optional argument for
specifying the month and the year in a key-value fashion:

  ┌────
  │ \issuesetup{143}
  └────
or:
  ┌────
  │ \issuesetup[month=3]{143}
  └────
or:
  ┌────
  │ \issuesetup[month=3,year=2016]{143}
  └────

but it is less explicit than:

  ┌────
  │ \issuesetup{number=143}
  └────
or:
  ┌────
  │ \issuesetup{month=3,number=143}
  └────
or:
  ┌────
  │ \issuesetup{month=3,year=2016,number=143}
  └────

OK, I could give a more explicit name: \issuenumber rather than
\issuesetup but:

1. \issuenumber[month=3,year=2016]{143} would look rather strange (has
   a "number" an optional "month"?)
2. other properties than just the number (and related month and year)
   could be added in the issue setup, hence \issuesetup is a more
   appropriate name than \issuenumber.

Thanks.
-- 
Denis

ATOM RSS1 RSS2