[pacman-dev] Rationale for the patch for case insensitive configuration values
Hi, I understand that case sensitivity can, perhaps, bring clarity for configuration values like ILoveCandy, but IMO, both "Never" and "never" should be allowed, as the uppercase letters bring no more clarity, but add an additional requirement for the users to conform to. That is the reason for the patch. Also, in the name of consistency, I changed all the checks in conf.c, not just the check for the word "Never". This is about simplicity and removing a constraint that users shouldn't have to relate to when editing pacman.conf. I tested both compilation and execution of the resulting pacman binary and it works fine here. -- Sincerely, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
On Tue, Jan 17, 2012 at 8:24 AM, Alexander Rødseth <rodseth@gmail.com> wrote:
This is not about simplicity, but "user-friendliness" or ease. Look at pacman.conf, every directive or option is in CamelCase, and the only things that are (likely) in lowercase are package and repo names and file paths. This distinction is good and increases clarity. By being case insensitive, you introduce complexity, allow this consistency to be broken and potentially reduce clarity.
Hi, 2012/1/17 lolilolicon <lolilolicon@gmail.com>:
I agree that the configuration options are currently in CamelCase and that this is the current situation.
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"? I think this is an artificial requirement that puts an extra burden on users, for no reason at all.
In what way is complexity introduced? 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. 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? Best regards, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
On Wed, Jan 18, 2012 at 4:37 AM, Alexander Rødseth <rodseth@gmail.com> wrote:
"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.
No, it's not simpler. It may be easier - if the user does not understand the convention (e.g. from a Windows background).
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).
On Mon, Jan 16, 2012 at 11:40 PM, lolilolicon <lolilolicon@gmail.com> wrote:
The below commit should speak for itself, we are never ever going back to case-insensitive comparison. ILoveCandy is a perfect example of the below i vs. I vs. ı vs. İ case. commit b3e6cf652c9e989badaf5499abb1d64c1a110927 Author: Chantry Xavier <shiningxc@gmail.com> Date: Thu Mar 13 16:36:44 2008 +0100 Drop case insensitive comparisons in the config parsing.
participants (3)
-
Alexander Rødseth
-
Dan McGee
-
lolilolicon