Is this an orthodox use of zstyle?

Is this an orthodox use of zstyle?

[DervishD]

    Hi all :)

    I think I can use styles to carry state information from one
widget execution to another, so the widget will behave differently
depending on the result of past executions, but: is this an orthodox
use of styles or is it more like using mozilla for opening my
/etc/hostname just because I can do it?

    I know that I can do this with an environment variable, but since
the state information can be a bit complex I will need an array, or
maybe a couple for separating information, or even an associative
one, and I think that the contexts and styles are very useful here.

    Just guessing if I'm trying to kill flies using a bazooka...
(sorry, can't find a better translation of this spanish expression...)

    Thanks a lot in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: Is this an orthodox use of zstyle?

[Bart Schaefer]

On Oct 14,  6:00pm, DervishD wrote:
} 
}     I think I can use styles to carry state information from one
} widget execution to another, so the widget will behave differently
} depending on the result of past executions, but: is this an orthodox
} use of styles [...]?

Typically functions read styles but don't set them, unless they're a
special kind of function that's designed to help the user set up his
environment (e.g., (in 4.1.1) select-word-style).

If the same function will behave differently depending on context
(e.g., it might be called as either a normal widget or a completion
widget) then styles might be appropriate, but if you don't need to
save different state in different contexts, parameters are better.

}     I know that I can do this with an environment variable but since
} the state information can be a bit complex I will need an array, or
} maybe a couple for separating information, or even an associative
} one

You presumably don't want to "export" the widget state parameters
(you can't export styles) so it's fine to use arrays and associative
arrays for your state.  For example, look at the set of parameters
used by the zftp functions to maintain state.

Re: Is this an orthodox use of zstyle?

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     I think I can use styles to carry state information from one
> } widget execution to another, so the widget will behave differently
> } depending on the result of past executions, but: is this an orthodox
> } use of styles [...]?
> Typically functions read styles but don't set them, unless they're a
> special kind of function that's designed to help the user set up his
> environment (e.g., (in 4.1.1) select-word-style).

    That's the cause of my question, I haven't seen this kind of use
in zsh functions (well, I haven't checked all...).
 
> If the same function will behave differently depending on context
> (e.g., it might be called as either a normal widget or a completion
> widget) then styles might be appropriate, but if you don't need to
> save different state in different contexts, parameters are better.

    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.

> }     I know that I can do this with an environment variable but since
> } the state information can be a bit complex I will need an array, or
> } maybe a couple for separating information, or even an associative
> You presumably don't want to "export" the widget state parameters
> (you can't export styles) so it's fine to use arrays and associative
> arrays for your state.

    Yes, you're true, 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?

> For example, look at the set of parameters
> used by the zftp functions to maintain state.

    Yes, I've took that as an example ;)) but then my idea about
using styles arose. I must admit that for simple state information, a
simple array is enough, or maybe one per 'session' (whatever you call
a session), but the power of styles is exciting ;)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: Is this an orthodox use of zstyle?

[Bart Schaefer]

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.

Re: Is this an orthodox use of zstyle?

[DervishD]

    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/

Re: Is this an orthodox use of zstyle?

[Bart Schaefer]

On Oct 15, 11:54am, DervishD wrote:
}
}     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).

Yes, you could write "zstyle" as a shell function.  There are a number
of parts of the completion system that could be written as functions,
but that were coded (or re-coded) in C for speed.

I think the caching utility (_store_cache, etc.) would be the next
candidate for that sort of conversion ... there's something else you
could use to store state, by the way.  Even slower than styles, but
sharable across multiple shells.

Re: Is this an orthodox use of zstyle?

[DervishD]

    Hi Bart :)

 * Bart Schaefer <schaefer@brasslantern.com> dixit:
> }     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).
> Yes, you could write "zstyle" as a shell function.  There are a number
> of parts of the completion system that could be written as functions,
> but that were coded (or re-coded) in C for speed.

    I'm not going to do that, anyway ;)) I was just guessing. The
fact is that although you can implement a bunch of builtins as shell
code, it's usually faster, safer, etc... to write them in C.

> there's something else you could use to store state, by the way. 
> Even slower than styles, but sharable across multiple shells.

    What's that? ;))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736
http://www.pleyades.net & http://raul.pleyades.net/

Re: Is this an orthodox use of zstyle?

[Bart Schaefer]

On Oct 15,  9:00pm, DervishD wrote:
}
} > there's something else you could use to store state, by the way. 
} 
}     What's that? ;))

I was referring to the _store_cache/_retrieve_cache mechanism ... but
on closer inspection it has :completion: style contexts hardwired, so
it'd need some tweaking.