On Fri, Oct 22, 2004 at 01:46:02PM -0700,
ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
I suppose this is as good a place as any for this comment: I'm not all
that comfortable with all strings being automagically eligible for
interpolation (once this extension's capability is enabled). It seems
to me that it would be better to have a syntax that specifically
commands that the string be processed. e.g., with some character before
the opening quote:
fileinto ?"${1}";
or via other different quoting style. A bonus would be a syntax that
allows one or more rescannings of the resulting string.
I think having this as a global setting is sufficient. You either
require variables and get the effect or you don't and the effect is absent.
That was the thing that I was attempting to find a cure for.. the
necessity of interpolating every single string once the capability has
been enabled. "require variables" isn't really a global setting,
in that you can't unset it.
I would imagine that in most scripts, very few strings will have
variable references. It simply strikes me as wasteful to process all of
them for interpolation just for the few that need it; plus it's just my
inclination to want such processing to be explicit rather than implicit.
(with the emphasis on the latter, really- as the extra processing
probably isn't major.) None of the alternatives that I could think of
were all that attractive to me though, including the one of
interpolating all strings all the time. But I figured I'd throw it
out there.
For ":matches", the list will contain one string for each wildcard
("?" and "*") in the match pattern. Each string holds what the cor-
responding wildcard expands to, possibly the empty string. The wild-
cards expand greedily.
I've lost track of the history: what's the reason for "*" expanding
greedily? Is it to be compatible with what regex does? My preference
(both in terms of what I'd expect and in terms of what is efficient to
implement) is the opposite. For example, let's say you have:
I'm afraid I don't buy your efficiency claims here. I can write efficient
greedy globbing code and I can write inefficient non-greedy globbing code.
What I was thinking of here was that some implementations (including the
one I am most familiar with) have a local hack or extension to allow
tests on the message body. And in time, when there are extensions to
support body and MIME part tests, existing match semantics will likely
be used. Doing a search in a message body, some of which may be cached
on disk, would be better done non-greedily. The efficiency of matches
on header strings is probably not all that big of a factor.
As for the utility of greedy ":matches" in scripts, I tend to think
non-greedy is more useful, but would welcome being educated by
examples of why that's not the case.
mm