Zsh Mailing List Archive
Messages sorted by:
Re: Is this an orthodox use of zstyle?
- X-seq: zsh-users 6705
- From: DervishD <raul@xxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: Is this an orthodox use of zstyle?
- Date: Wed, 15 Oct 2003 11:54:27 +0200
- Cc: Zsh Users <zsh-users@xxxxxxxxxx>
- In-reply-to: <1031015062143.ZM23223@xxxxxxxxxxxxxxxxxxxxxxx>
- Mail-followup-to: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>, Zsh Users <zsh-users@xxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Organization: Pleyades
- References: <20031014160041.GA343@DervishD> <1031014164250.ZM22562@xxxxxxxxxxxxxxxxxxxxxxx> <20031014171741.GG211@DervishD> <1031015062143.ZM23223@xxxxxxxxxxxxxxxxxxxxxxx>
Hi Bart :)
* Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> dixit:
> Ask yourself whether you'll ever be looking up the state with a
> more-specific context than that under which you stored it.
I know what you mean... The power of zstyle is not in precise
contexts... Most of the time I will know the exact context the style
is in, and right now I cannot think of a case where loose context
will be needed (except for configuration) in my widgets...
> However, if you've got some really creative way to use "zstyle -e" or
> some such, go for it.
That's the point: I have a couple of places where this would be
useful, to discriminate behaviour. That can be done with parameters
too, at least in my case, but will be a good point to learn.
> } [...] 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.
You're right, although I prefer to pollute zstyle namespace
rather than parameter namespace. I feel more comfortable adding a
:myname: context than using myname_whatever for each and every
parameter. But this is not a reason, of course.
> 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.
Speed is not an issue (well, to a certain extent), nor notation.
It's more a desire to learn and practice styles. Moreover, what I
consider more important is the possible need of styles in future
widgets I write. I think that introducing the style mechanism right
now, from the beginning, is a better idea.
> 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.
This is another cause for my original question. The retrieval of
style information in an array-like fashion has not a comfortable
notation. Parameters are better suitable for this.
I think that styles are a very attractive way of storing
contextual information, although not always needed, since you can
store contextual information using parameters, for example. In this
sense, zstyle may be abused, or misused. But the fact is that if you
want to store state information, or configuration options, for a
simple function or script, you can do with parameters. But if you
start to make more complex functions, interrelated ones, entire
systems, etc... you will surely need zstyle, since the contexts are
sometimes incomplete or unknown; then it is better IMHO that styles
are introduced from the beginning.
A last point: maybe I'm missing something, but I think that the
entire zstyle thing can be done with parameters (with exception of
the -e option, maybe). Excuse me if that sounds stupid or clueless,
but I haven seen many uses of zstyle (I haven't read all the
completion code... by now...).
Thanks again Bart. Remember that dinner if you come to Spain ;)
Raúl Núñez de Arenas Coronado
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/
Messages sorted by: