Re: [Gramps-devel] Getting rid of globals (e.g. Config)

[Douglas S. B. <db...@cs...>]

On Fri, February 22, 2008 3:05 am, Benny Malengier wrote:
> 2008/2/22, Brian Matherly <br...@gr...>:
>>
>> Richard,
>>
>> <disclaimer>
>> The following text is full of brainstorming,
>> conjecture and open-ended thoughts. It should in no
>> way be misconstrued by the reader to be a
>> recommendation for a specific change to the code.
>> </disclaimer>
>>
>> Returning back to the whole reason this topic came up
>> (The dependency of Date upon Config):
>>
>> Looking at Date, I see that the only place Config
>> parameters are used is in get_start_stop_range() which
>> is only used by the match() function.
>>
>> The three config parameters are:
>>
>>     Config.DATE_BEFORE_RANGE
>>     Config.DATE_AFTER_RANGE
>>     Config.DATE_ABOUT_RANGE
>>
>> I bet someone could make a pretty good argument for
>> consolidating those three parameters into one named
>> something like "FUZZY_DATE_RANGE".
>>
>> Once consolidated, one could make a decent argument
>> for making that value a parameter to the match()
>> function (with a reasonable default value, of course).
>> Once it was a function parameter, the Date module
>> would no longer depend on Config.
>>
>> I can imagine a scenario where the application may
>> want control over that parameter. Consider a report
>> designed to make place/time associations between
>> people (eg. all people born in England between 1700
>> and 1900). The report author may want to make the
>> fuzzy date range an option for the user (so they can
>> choose to include or exclude a person born "before
>> 1904"). The way it stands now, the only way to make
>> that happen is by changing the Config value (which as
>> far as I can tell, can't be done from the GUI).
>>
>> I'm sure Doug can find a rebuttal for all my
>> conjecture. But my point isn't to have us change the
>> Date module. I guess that what I'm getting at is that
>> perhaps we should FIRST take a close look at all the
>> places we use Config, and make sure that is the best
>> solution (not just the easiest). THEN we can look for
>> an elegant architectural solution to the "global"
>> problem. I would bet that we can find plenty of places
>> were the Config dependency can be removed, or moved up
>> a layer without much trouble.
>
>
> The reason for Config of these paremeters is to allow the  advanced user
> to
> easily change them by editing keys.ini. They used to be hard coded, which
> meant it was easy to change them for developers (I think Doug used to use
> different values from default) but not for users who complained about the
> results they get from a date match filter.
>
> Making them parameters would not be a problem, except that almost all date
> calculation will use match(), so a developer should never ever forget to
> get
> them from Config and pass them through. That also is not that elegant.
> I think that is what should be avoided: having to rely on the developer to
> pass the parameters from Config if we know that is where the user can
> change
> them globally. However, still allowing to overrule them by having
> parameters
> to change default Config behavior would not be bad, that is, if ever such
> a
> report/tool is made.
>
> A lot of talk for few lines of code :-)

Benny et al,

(ditto on the disclaimer)

Talking about this particular code gives us something concrete, but I do
want to mention the philosophy of how this code came to be, and that might
shed some light on the config/global/parameterize from above issues in
general.

The original code I had written was not user-configurable, but was
designed to "do the right thing" based on the context. I had put some
thought into how the birthdate "before 2002" was different in meaning from
the birthdate "before 1700". One is recent and specific, and probably
means a small range; the other is remote and less specific, and probably
means a much larger range.

Of course, I had also made fine-grained distinctions between "about",
"before", and "after". (My background is artificial intelligence, so I
thought that this would be a good place for a little smarts.)

But, the code had a lot of somewhat arbitrary, hardcoded values. Also, I
think most of the developers have an engineering background and the idea
of code doing different things in different contexts based on 10
parameters was not looked upon favorably :) So, I removed the
context-dependent code and reduced the complexity to 3 variables (with the
hope of being able to turn on the "auto" context-based system again in the
future.)

The main point, I guess, is that I'll probably always think about how a
user's preference (from above) might be used in low-level code. I also
like the idea of combining all of the current preferences and the keys.ini
together. It is always a pain to try to decide which of these values
should be easy to change/see, and which ones should be hard/hidden.
Putting them all in a big list with proper interface, and
self-documentation, seems like a good thing. Is that part of Richard's
plan?

In any event, whether date.py needs config or not, the issue remains that
there will no doubt be config needs in many places. It would be cool if a
new system:

- was easy for the programmer to use (get, run code on changed values, set)
- had portable defaults: doesn't need defaults and fallbacks (that sounds
like defaults in two places)
- was easy for the user to change all values
- was upgradeable

Of course, I'm not suggesting that Richard do all these things, but that
we could continue to work on a config system if we start with a flexible
framework.

-Doug

> Benny