FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 01-17-2012, 07:37 PM
Alexander Rødseth
 
Default Rationale for the patch for case insensitive configuration values

Hi,


2012/1/17 lolilolicon <lolilolicon@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)
 
Old 01-18-2012, 05:27 AM
lolilolicon
 
Default Rationale for the patch for case insensitive configuration values

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).
 
Old 01-18-2012, 03:10 PM
Dan McGee
 
Default Rationale for the patch for case insensitive configuration values

On Mon, Jan 16, 2012 at 11:40 PM, lolilolicon <lolilolicon@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 8:24 AM, Alexander Rødseth <rodseth@gmail.com> 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 <shiningxc@gmail.com>
Date: Thu Mar 13 16:36:44 2008 +0100

Drop case insensitive comparisons in the config parsing.
 

Thread Tools




All times are GMT. The time now is 04:25 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org