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

[lolilolicon]

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