On Mon, Jun 12, 2017 at 01:04:09PM -0700, Jonathan Tan wrote:
> > I'm not sure I know what you mean by config variables which are static,
> > are you referring to the in-memory options which are populated by
> > querying the config? Those I wouldn't want to see placed in a
> > 'repository object'.
>
> Yes. I agree that I wouldn't want to see them placed in a repository
> object, but after reading Peff's e-mail, I was thinking of what happens
> if a file repeatedly invokes a config-sensitive function in another
> file. For example:
>
> a.c
> for (i = 0; i < 100; i++) b_output(repo, x);
>
> b.c
> void b_output(struct repository *repo, int x)
> {
> /* print the configured "b.prefix" followed by x */
> }
>
> We probably wouldn't want to parse the repo's configset every time
> b_output() is invoked, but then, where to store our parsed "b.prefix"?
> The only alternatives I see is to have a static hashmap in b.c (keyed by
> repo, as described above), which would work if such a situation is rare
> (or can be made rare), but if it is common, maybe we have no choice but
> to put it in struct repository.
I think besides optimization, we often parse the textual config into
variables and then _modify_ those variables based on other input (most
often command-line arguments provided by the user, but sometimes other
circumstances).
You can move the resolution to the point-of-use instead of
point-of-setting, but that's going to be a big change to how most of the
code already works.
-Peff
