Subject: | |
From: | |
Reply To: | |
Date: | Mon, 16 May 2011 14:51:28 -0700 |
Content-Type: | multipart/alternative |
Parts/Attachments: |
|
|
I really wish that the positional thing was somewhat deprecated in favor of a
named argument approach, which would replace the limit of 9 at some point.
Paul Thompson
Professor and Senior Scientist
Director, Methodology and Data Analysis Center
Sanford Research
900 W Delaware
Sioux Falls, SD 57104
O: 605-312-6462
M: 618-974-0473
H: 605-332-1587
F: 605-328-0401
909 N. Charleston Circle
Sioux Falls, SD 57110
605-332-1587
________________________________
From: Frank Mittelbach <[log in to unmask]>
To: [log in to unmask]
Sent: Mon, May 16, 2011 4:41:54 PM
Subject: Re: xparse and space skipping
> On 16/05/2011, at 3:39 PM, Joseph Wright wrote:
>
> > To me, that means
> >
> > \foo[...]{...}
> >
> > is a possible, but I'd hope not
> >
> > \foo{...}[...]
>
> I think there are enough examples on CTAN where people have needed to
> extend the optional argument syntax to indicate that the 2e model above is
> too restricted for user purposes.
--text follows this line--
A simple syntax with unnamed positional arguments (optional or mandatory or
mixed) as 2e provides it has its uses and they go beyond a single optional
argument. But clearly this is a syntax that very fast gets difficult to use or
rather to remember. It all depends on how strong the arguments are "naturally
ordered" and how often such commands are used.
>
> Having said that, I do agree in some cases (such as \makebox[][]{}) an
> overload of optional arguments is also a bad idea, where a keyval interface
> makes more sense.
I guess there are worse ones but yes, those kind of commands are good examples
were such a syntax is fast reaching its limits especially as the commands are
seldom used. But if a command is used often enough you can keep a consise
syntax and still have it fairly complex.
Anyway, I'm not arguing key/val no key/val. I'm quite a fan of the letter
(sometimes)
> Dropping trailing optional arguments just doesn't feel right to me; in the
> interests of disclosure, however, at least two of the packages I've written
> (pstool and mlist) use them, so I'm clearly biased :) Their interfaces
> could certainly be revised but I don't think (yet) in hindsight that the
> way the commands work therein is necessary a bad idea.
I wouldn't drop them either (not for xparse anyway) and I think that Lars'
suggestions needs a closer look at to perhaps provide the best of both worlds
even here.
frank
|
|
|