darcs patch: include all source code in LOC count.

This patch has us include the hs-boot file as source code, which only seems
fair. After all, it's yet another bit of code that needs to be kept in
sync with the rest.
David
Thu May 3 07:05:51 PDT 2007 David Roundy

On Thu, 03 May 2007 07:45:37 -0700
David Roundy
This patch has us include the hs-boot file as source code, which only seems fair. After all, it's yet another bit of code that needs to be kept in sync with the rest.
I'm not sure that I agree with this sentiment. I'd consider hs-boot a part of the build system, to get around GHC's mishandling of module cycles. Anyone else have an opinion? Cheers, Spencer Janssen

sjanssen:
On Thu, 03 May 2007 07:45:37 -0700 David Roundy
wrote: This patch has us include the hs-boot file as source code, which only seems fair. After all, it's yet another bit of code that needs to be kept in sync with the rest.
I'm not sure that I agree with this sentiment. I'd consider hs-boot a part of the build system, to get around GHC's mishandling of module cycles.
Anyone else have an opinion?
.hs-boot doesn't count, imo.

On Thu, May 03, 2007 at 03:28:06PM -0500, Spencer Janssen wrote:
On Thu, 03 May 2007 07:45:37 -0700 David Roundy
wrote: This patch has us include the hs-boot file as source code, which only seems fair. After all, it's yet another bit of code that needs to be kept in sync with the rest.
I'm not sure that I agree with this sentiment. I'd consider hs-boot a part of the build system, to get around GHC's mishandling of module cycles.
Anyone else have an opinion?
I think the whole LOC counting thing is somewhat silly to begin with and I would prefer to abandon the whole idea of keeping xmonad under some arbitrary number of lines. This is probably a sign of personal laziness, but I find the LOC limit has a "chilling effect" on certain types of refactorings. ("hmm...this line is getting kinda long...I should probably break that out over a couple lines...but that will increase the LOC count...") I'm sure if I was a cool uber-hacker, I'd go ahead and break it out over a couple lines, and then make up the lines somewhere else in some other clever, clean refactoring. But I'm not, and in my case, at least, laziness seems to win out. Of course, the other side of that coin is encouraging refactors that reduce LOC legitimately. ISTR whining to dons about the pointlessness of counting LOC earlier, and he said that the LOC limit in dwm had helped create a culture of refactoring in that community. Would you mind expanding upon that a little bit, Don? WRT the actual issue at hand, I don't know. It's somewhat like having to have a .h file in C. They *should* be auto-generated, but they aren't. Does dwm count .h files? Jason Creighton

jcreigh:
On Thu, May 03, 2007 at 03:28:06PM -0500, Spencer Janssen wrote:
On Thu, 03 May 2007 07:45:37 -0700 David Roundy
wrote: This patch has us include the hs-boot file as source code, which only seems fair. After all, it's yet another bit of code that needs to be kept in sync with the rest.
I'm not sure that I agree with this sentiment. I'd consider hs-boot a part of the build system, to get around GHC's mishandling of module cycles.
Anyone else have an opinion?
I think the whole LOC counting thing is somewhat silly to begin with and I would prefer to abandon the whole idea of keeping xmonad under some arbitrary number of lines. This is probably a sign of personal laziness, but I find the LOC limit has a "chilling effect" on certain types of refactorings. ("hmm...this line is getting kinda long...I should probably break that out over a couple lines...but that will increase the LOC count...") I'm sure if I was a cool uber-hacker, I'd go ahead and break it out over a couple lines, and then make up the lines somewhere else in some other clever, clean refactoring. But I'm not, and in my case, at least, laziness seems to win out.
Of course, the other side of that coin is encouraging refactors that reduce LOC legitimately. ISTR whining to dons about the pointlessness of counting LOC earlier, and he said that the LOC limit in dwm had helped create a culture of refactoring in that community. Would you mind expanding upon that a little bit, Don?
I think its an interesting exercise, and there's no reason to abandon it just yet. The loc limit encourages precision, getting the exact patch we want. As with dwm, but even moreso, it is encouraging a culture of refactoring. And that's a good thing for a window manager that is supposed to be a precision machine, built up from pure components and QuickCheck properties :-) -- Don
participants (4)
-
David Roundy
-
dons@cse.unsw.edu.au
-
Jason Creighton
-
Spencer Janssen