[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