On Wed, Jan 18, 2012 at 4:37 AM, Alexander Rødseth <rodseth@gmail.com> wrote:
This distinction is good and increases clarity.
Here I disagree, as I think requiring "never" to be written as "Never" is a form of noise. I think it's equally clear to allow "Never" to be written as "never", while having the added benefit of not having to remember the casing for the configuration options in addition to the actual letters. InWhatWayIsCamelCaseAnyClearer than using regular lowercase words? Even if you think "ILoveCandy" is distinctivly clearer and far more well defined than "ilovecandy", do you also think so for "Never" vs "never"?
"Never" is just a special case of CamelCase, you can't argue that CamelCase in this context is not clearer than alllowercase just because "Never" is not clearer than "never". And actually, "Never" _is_ clearer than "never" in the context of pacman.conf, since it signifies that it's not a package name and more likely an special option (or constant).
I think this is an artificial requirement that puts an extra burden on users, for no reason at all.
I do not see any extra burden, really. If you consider this a burden, you probably would agree that the unix shell being case sensitive put a huge burden on users. On the contrary, being case insensitive will put more burden on programmers. Think of a shell script that parses pacman.conf - the author needs to first realize that pacman.conf is (*now* *partly*) case insensitive, and then use more code to match the options. This is bad.
In what way is complexity introduced?
Case insensitive is by definition more complex than case sensitive.
In the source code, it's still just one standard function call to compare the strings. Is it more complex for the users? No, it's not, it's simpler.
No, it's not simpler. It may be easier - if the user does not understand the convention (e.g. from a Windows background).
In what way is inconsistency introduced? When upgrading packages? When users share configuration files? I can't think of any case where "consistency will be broken". Do you have a likely scenario in mind? Is it the fear of users writing "Never" as "nEvEr" in their own personal configuration files?
The current convention of CamelCase is very clear and easy to grasp. As I indicated in my last mail, CamelCase makes the options stand out, which is self-clarifying. If you allow "never" or "packagerequired", it obviously will reduce clarity as well as break consistency between the special options. What you described ("nEvEr") is also a valid concern why case insensitive is bad - it can introduce noise in communicating (e.g. in IRC help).