[darcs-devel] Greetings and some questions
Dino Morelli
dino at ui3.info
Mon Oct 2 11:57:11 PDT 2006
On Mon, 2 Oct 2006, Tommy Pettersson wrote:
> Hi Dino,
>
> On Mon, Oct 02, 2006 at 11:19:00AM -0400, Dino Morelli wrote:
>> On Mon, 2 Oct 2006, Eric Y. Kow wrote:
>>
>>>> I was thinking about it, and if nobody thinks it's too nitpicky, it would
>>>> be somewhat better if the string literal "--case-ok" wasn't used here
>>>> (and also in Add.lhs) I was tinkering with some code as shown below to
>>>> extract the long option name programmatically.
>>>
>>> Good thought. Perhaps you could make a function like
>>> getLongDarcsOption :: DarcsOption -> String
>>> -- I am horrible with function names; pick something reasonable
>>>
>>> So that you can just say (getLongDarcsOption allow_caseonly).
>>>
>>> This has the added benefit of avoiding stuff like head.
>
> I don't agree with Eric on this. Option names will not change.
> And when they do, we're sure to get bug reports from users if we
> forget to update the documentation. And when we don't, darcs is
> doing fine anyway. (Ok, the last one is bad attitude, but it
> sounds smart.) Anyway, we don't need an abstraction layer for
> the spelling of option names, do we really?
>
> Sorry to be against. I won't fight it vividly if Eric still
> likes it.
>
I feel that it's bad to hard-code strings like this in general. That
said, I do understand what you mean about an 'abstraction layer', at
some point you can get out of control abstracting things and make the
code a PITA to work on.
I was hoping it would be a simple thing to reach into the already defined
option expression and take the string from there, but now I have the
(see other email to list) complaint about the import cycle. I guess this
is threatening to turn into a refactor because of that. :/
--
.~. Dino Morelli
/V\ email: dino at ui3.info
/( )\ irc: dwm
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org
More information about the darcs-devel
mailing list