[pacman-dev] Rationale for the patch for case insensitive configuration values

newer
[pacman-dev] [PATCH] Fix missing...

Alexander Rødseth

17 Jan 2012 17 Jan '12

1:24 a.m.

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)

Show replies by date

lolilolicon

17 Jan 17 Jan

6:40 a.m.

New subject: [pacman-dev] Rationale for the patch for case insensitive configuration values

On Tue, Jan 17, 2012 at 8:24 AM, Alexander Rødseth wrote:

...

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.

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.

...

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)

Alexander Rødseth

9:37 p.m.

New subject: [pacman-dev] Rationale for the patch for case insensitive configuration values

Hi, 2012/1/17 lolilolicon :

...

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.

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.

...

By being case insensitive, you introduce complexity, allow this consistency to be broken and potentially reduce clarity.

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)

lolilolicon

18 Jan 18 Jan

7:27 a.m.

New subject: [pacman-dev] Rationale for the patch for case insensitive configuration values

On Wed, Jan 18, 2012 at 4:37 AM, Alexander Rødseth 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).

Dan McGee

5:10 p.m.

New subject: [pacman-dev] Rationale for the patch for case insensitive configuration values

On Mon, Jan 16, 2012 at 11:40 PM, lolilolicon wrote:

...

On Tue, Jan 17, 2012 at 8:24 AM, Alexander Rødseth wrote:

...
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.

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.

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 Date: Thu Mar 13 16:36:44 2008 +0100 Drop case insensitive comparisons in the config parsing.

4488

Age (days ago)

4489

Last active (days ago)

List overview

Download

4 comments

3 participants

participants (3)

Alexander Rødseth
Dan McGee
lolilolicon