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

Alexander Rødseth rodseth at gmail.com
Tue Jan 17 15:37:21 EST 2012


Hi,


2012/1/17 lolilolicon <lolilolicon at gmail.com>:
> 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)


More information about the pacman-dev mailing list