Re: Is this an orthodox use of zstyle?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 14,  7:17pm, DervishD wrote:
}
}     Well, the first widgets I want to modify using state information
} really don't need contexts, but I think that I may need it in the
} future, for example if I write any completion widget (I don't use
} compsys), so it may be a good thing using styled from the beginning.

That's a good argument for looking up configuration options with styles,
but not for storing transient state with zstyle.  Ask yourself whether
you'll ever be looking up the state with a more-specific context than
that under which you stored it.  If the answer is that you always know
the precise context for both storage and retrieval (even if there may
be more than one such context), then parameters are probably the better
way to go.

However, if you've got some really creative way to use "zstyle -e" or
some such, go for it.

}     [...] I don't want nor need to export the state, so
} this is not an issue. Anyway, since styles doesn't pollute namespace,
} wouldn't be better to directly use them for storing state information
} even without contexts?

True, styles don't pollute the parameter namespace, but they do pollute
the zstyle namespace.  In either case all you need is a convention for
your names that isn't likely to collide with someone else's convention.

Drawbacks of using zstyle for transient data:

Styles are looked up by matching a series of pattern keys against the
probe, rather than by matching a single pattern probe against a series
of keys.  It's therefore more expensive to look up a style than a
parameter.  (It's like using ${assoc[(k)probe]} when ${assoc[probe]}
would suffice.)

To use styles as arrays or associative arrays, you have to assign them
to a parameter with "zstyle -g", then reset the style from the value
of the parameter again to save the state.