ietf-mta-filters
[Top] [All Lists]

Re: variables draft (draft-homme-sieve-variables-00.txt)

2003-04-08 12:47:58

[Tony Hansen]:

  Kjetil Torgrim Homme wrote:
  >>  Other languages have benefitted from namespaces. It might be
  >>  worthwhile exploring that concept, particularly if there are
  >>  preset variables. For example, instead of the preset variable
  >>  name ${year}, you'd instead have ${time.year}. Thoughts?
  >
  > how should the namespace namespace be governed?  a registry?
  > only available to extensions specified in RFCs?
  
  If setdate is comparable to a "require", then defining such an
  addition should define the namespace that it places its data into.
  Perhaps it should be ${setdate.year}, ${setdate.month}, etc.

this would work.  (there need not be a one-to-one relationship between
the name of the action/extension and the namespace, "date.year" would
work just as well.)

essentially, this is "only available to extensions specified in RFCs".
the question is if it's needed, the variable names themselves will be
carefully controlled and collisions can be avoided relatively easily.
the main benefit is that system variables look syntactically different
from user variables, and we could also make them read-only if we like.

it seems to me that namespaces are more useful if the user are allowed
to use them.  however, the user can do that, simply by imposing his
own rules for variable naming.  e.g., prefix all variables with "kj_".

  More complex packages might want to use more fully qualified
  names:
  
      require "example";
      setfoo ...;
      setbar ...;
  
      ${example.foo.handle}
      ${example.bar.contenttype}
  
  to make certain that they don't conflict with the "foo" and "bar"
  namespaces of other "require" constructs.

nice, but I think this is over-engineering, and most of the effect can
be had by substituting an underscore for the period.

-- 
Kjetil T.

<Prev in Thread] Current Thread [Next in Thread>