On 8/23/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 23.08.2006, at 17:20, Andrew Piskorski wrote: > That's only necessary to preserve the current ns_config > case-insensitivity, right? Wouldn't it be easier to just canonicalize > the key values on both write and read? E.g., create a wrapper around > nsv which forces all keys to all lowercase. Then the key "Foo_Bar" > will be automatically translated to "foo_bar" in all situations. This is also a posibility I was thinking of. This would work, but then if you would want to generate a dump of the config later on, you would loose the case. If somebody made this: ns_config ns/section/something ns_param MyParam 1 and if we would to re-create the setup in order to put it in the file again, the case would be lost, so the param will not be called "MyParam" but "MYPARAM" or "myparam" whatever case you selected. I do not know if this is/would-be an issue for anybody, but this is important to know. If you ask me: I would go with that and with the nsv as I believe this is most optimal in case of needed work and final result. But I must see that we do not shoot ourselves in the foot by some wrong design decision. Hence so much fuss.
Reading today's developments on this thread, I am glad to know that by the time I got to the bottom others had the same thoughts as I. Reusing nsv for the config makes most sense to me - removes code to add functionality and flexibility. This always seems like the correct path. Making the config file canonical isntead of the silly case insensitivity also makes a lot of sense. I do think a sanity check is in order when reading the config file - while dealing with config file and collapsing the case, it makes sense to check that no other case-version of the same key has been seen and at least issue a warning. This might be a bit too expensive to include, but maybe a good idea. I do have one concern with this change - what happens when the value (where case must be preserved) for some key is actually the name of another section or key? I do not have enough experience to tell if this is ever a problem, but I am not sure how this situation would be handled. Perhaps by the code that uses that config value?
