[Ned Freed]:
> according to Marc, the variables extension was wanted to make
> imapflags blend in better. isn't it a mistake to press on
> before we have decided how imapflags should operate?
It isn't what I wanted it for. While the imapflags extension can
be useful, the uses I see it being put to don't require variables.
good. that's my view as well, so then I'm not completely out of line :)
> actually, as long as MARK/UNMARK are kept, the variable name
> must be implicit and fixed. and so we're back at the
> system/read-only variable discussion ;-)
And I have stated repeatedly that I view this as "mostly
harmless".
yeah. I think I'll start a new thread on this.
> every variable can be used as a list variable. every list
> variable can be used as a string variable. I just think that's
> easier to grasp. I _definitely_ don't want separate namespaces,
> like in Perl where @var and $var are different.
You're missing the point, which is that variables are typed: Each
one is either a string or a list.
says who? make all variables lists internally, or promote strings
when needed. either would work.
The fact that string variables can be coerced into something else
in a list context and vice versa doesn't mean that the underlying
variable isn't typed.
the user can not tell what the implementation does.
Now, perhaps you're trying to get rid of variable typing by making
everything completely mutable. But this just doesn't work: The
rules for how a given variable are handled in various contexts
depend on knowing whether the underlying variable is a string or a
list. And this means
set var "foo"
had darned well better set the variable "var" to the _string_
"foo".
with my proposed semantics there is no observable difference.
but let's leave this discussion, it's not useful.
> I'd like to focus on giving imapflags what it needs. it's not
> at all clear list variables are needed.
Exactly what I have been saying over and over and over again.
so have I, I just presented three alternatives. why didn't you help
me flesh out your favourite alternative rather than pull authority on
your least favourite?
--
Kjetil T.