On Mon, 2005-02-07 at 14:19 +0000, Nigel Swinson wrote:
Each phone number must begin with a + and
include the country code to ensure that the script will work
regardless of location of server/script.
is it important to trap this at compile-time?
I think it's similair to the desire to catch invalid variable names at
compile time. So yes, I think so.
I agree it is desirable, and if we have mechanism specific keywords,
arguments should be syntax checked as much as possible.
if header :matches "*" "To" {
(you'll have to switch the arguments, it's header COMPARATOR header-name
pattern)
sorry, this should say "header MATCH-TYPE header-name pattern"
Ug I never did find the order intuative...
it is intuitive if you use the default match-type ":is". the
non-intuitive bit is the placement of the match-type, but it is a basis
for the syntax that all tagged arguments appear before positional
arguments.
greediness doesn't come into play here, as :matches "*" == :regex
"^(.*)$"
I'm happy that that is the case but is that obvious to everyone? It
wasn't obvious to me, and I don't recall reading that it was ever
specified. I think we have another thread on this topic though...
I think we agreed previously that 3028bis should be more explicit about
the meaning of wildcards in the argument to :matches. I think it is
non-controversial, though, nobody would expect "abc" to match "b*".
$HEADERS[‘Received’][0] = "from p01m168.mxlogic.net [bla bla] "
$HEADERS[‘Received’][1] = "from unknown [208.184.76.39] [bla bla] "
$HEADERS[‘Date’][0] = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
this is just a different syntax for:
${header.received.n1} = "from p01m168.mxlogic.net [bla bla] "
${header.received.n2} = from unknown [208.184.76.39] [bla bla] "
${header.date} = "Thu, 27 Jan 2005 09:56:56 -0800 (PST)"
Yes, I would have suggested that instead, but I suppose I wondered if
such a mechanism would mean we'd have to predefine all header names
we'd ever use. I thought perhaps the use of the associative array
made it clearer that the header might not actually exist in the email,
and therefore cope with all future header names.
that's really for the extension to decide. the variables draft doesn't
rule out having variables spring to life when referenced -- it only
specifies the syntax of the names. how the variables inside a
namespace work is left for the extension to define.
I would prefer the list of supported header names was explicit, though,
so that the extension could do the relevant decoding for the user.
notice that I omitted the number suffix for header.date, since RFC 2822
explicitly says there should be 1 and only 1 "Date" header.
(the variables draft doesn't allow the last component of the variable
name to be a number. I think that is an aspect we can change if we want
to, but it must be done now.)
I think it preferable to allow array syntax instead of variables
starting with numbers.
I'm afraid I don't see that happening, the variables draft is too close
publication for such a change to the syntax.
anyhow, doing it via a namespace makes it more natural to present the
information in a parsed manner. e.g., you could have an
header.date.year == "2005" in addition.
Indeed, that might work neatly!
If we were to do this then where would such a mechanism be specified?
3028bis, variables, new draft? I'd love it to be available in the
variables spec...
the namespace feature of the variables draft was specifically added to
allow independent extensions to add "magic" variables.
--
Kjetil T.