[Top] [All Lists]

Re: Variables : list : scope : system : const

2003-05-09 08:29:21

[Ned Freed]:

  > > this could be solved by making making a new list variable syntax,
  > > e.g., @{folder} becomes a list, while ${folder} becomes a single
  > > string with a single space as delimiter or something.
  > With all the stuff and points that are getting raised I'm
  > becoming increasingly convinced that:
  > 1) We should implement list variables (maybe even associative
  > variables), and implement the imapflags extension using the list
  > variables.  Perhaps one extension that deals with the syntax,
  > the operators (including operators to turn it into a string), or
  > perhaps it could be part of the imapflags one...  I'd prefer
  > them separate I think...  If we implement imapflags without list
  > variables, then get further down the line and find we can't live
  > without them, then we'll just end up wishing we had them for the
  > imapflags extension.

  I disagree 100%. I think this is far too complex.

what's your preferred alternative in the imapflags case?

A string containing a list of flags separated by spaces. This is hardly
rocket science.

  There are also very substantive syntactic difficulties with making
  such usage compatible with the base sieve specification.

please state them so that they can be addressed.

They have all been stated before. For exmaple, what syntax do you
use to plug a list variable into an argument to a test? "&list" is
poor. What about "&list &list"? What about ["&list", "&list"].

Sure, you can work around all of this. But it keeps getting uglier and
uglier. And for what? A feature that is nice to have at best?

  > 5) We don't have any "system variables" or "magic variables",
  > JUST "variables".  So if we want setdate to produce variables
  > for us to use elsewhere then they either go out to some
  > associative array, or a set of variables in an appropriate
  > namespace that can subsequently be written to if the script
  > author so desires.  I don't want to have to deal with two+
  > classes of variables :o(

  You may not want to deal with them, but it may make sense to
  implement things using a multi-tiered storage approach.

what do you mean?

I mean I may not want to create variables like year, month, day, and so on on
demand rather than having setdate poke them into the same structure used for
user-defined variables.

  > 6) If we really want a class of variable that can't be written
  > to then lets implement const variables.

  Vastly too complex IMNSHO.

well, it's the alternative to system variables, which I find vastly
too complex ;-)

The question is whether we actually need them. I've yet to be convinced we do.
But if we do, this can be done as part of a naming convention, rather than by
defining more operators and such.

  Simplicity per se is not the issue, nor is the ability for fools
  to write scripts. The central concerns here all revolve around
  implementability, performance, and security. When complexity comes
  up as a concern, it is because something is seen as being too
  difficult to implement in the context of a a high performance
  messaging server. Things like lists, associative arrays, and so on
  raise the bar hugely, creating implementation complexity and
  thereby increasing the risk of security problems.

I agree, but a powerful variables concept may pay off when
implementing later extensions.  I think it is important that we try to
keep the language and mechanisms coherent, and add features that
complement each other and are more powerful in unison.

Exactly. The primary problem with list variables is that they clash very very
badly with earlier design choices, so much so that we lose considerable
language coherency by adding them. Now, you can argue that earlier design
choices were poor ones, but that doesn't make them go away.