zsh-users
 help / color / mirror / code / Atom feed
From: DervishD <raul@pleyades.net>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh Users <zsh-users@sunsite.dk>
Subject: Re: Is this an orthodox use of zstyle?
Date: Wed, 15 Oct 2003 11:54:27 +0200	[thread overview]
Message-ID: <20031015095427.GN867@DervishD> (raw)
In-Reply-To: <1031015062143.ZM23223@candle.brasslantern.com>

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> 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/


  reply	other threads:[~2003-10-15  9:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-14 16:00 DervishD
2003-10-14 16:42 ` Bart Schaefer
2003-10-14 17:17   ` DervishD
2003-10-15  6:21     ` Bart Schaefer
2003-10-15  9:54       ` DervishD [this message]
2003-10-15 15:15         ` Bart Schaefer
2003-10-15 19:00           ` DervishD
2003-10-16 14:40             ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031015095427.GN867@DervishD \
    --to=raul@pleyades.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-users@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).