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: [EMAIL PROTECTED]
/( )\ irc: dwm
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
