Ar an dara lá is fiche de mí Eanair, scríobh Stephen J. Turnbull:
Aidan Kehoe writes:
> It's hostile--at least on the collaborative level--to a style of
> coding that moves piece by piece, going back to fix mistakes made
> originally when they become clear.
Any "hostility" is in your own mind. For one thing, I think that
style is perfectly acceptable in the packages, if the package
maintainer is happy with it.
But let's see about this style. First, give it its proper name:
In a wide sense, ‘code-and-fix’ is, well, development in general. You
haven’t narrowed down what you’re arguing against to have it be anything but
a straw man. I get your frustration at bugfixing, but refactored code is not
necessarily bug-free code. Code with common interfaces is not necessarily
bug-free code. The best we can do is make it easier to fix bugs, and forcing
me to put time and thought into replying to a 700-word articulate essay from
you in reaction to what I thought--reasonably enough--does not foster a
perception that it’s easy to fix bugs.
How about collaboration? There wasn't any! You didn't discuss
anybody, you just committed it.
I’m confused as to why you think collaborative development and committing
code are mutually exclusive. The code is anything but re-inforced concrete;
there’s no need to bring in bulldozers or anything of the kind to change it.
Here’s a clear example of the kind of collaborative development I’m talking
Documentation of the design? None!
Hmm? I updated the docstring:
＠＠ -824,7 +824,7 ＠＠ Otherwise, list elements are:
First integer has high-order 16 bits of time, second has low 16 bits.
5. Last modification time, likewise.
6. Last status change time, likewise.
- 7. Size in bytes. (-1, if number is out of range).
+ 7. Size in bytes. (-1, if number out of range and no bignum support.)
8. File modes, as a string of ten letters or dashes as in ls -l.
It’s terse, certainly, but that’s true of docstrings in general.
Consideration for interaction with desirable future features? None
Oh good God. I saw the change as a bugfix. Someone (cvs annotate says steve,
but this was in the first revision, so it probably predates CVS) had
previously identified the issue:
- values = make_int ((EMACS_INT) s.st_size);
- /* If the size is out of range, give back -1. */
- /* #### Fix when Emacs gets bignums! */
- if (XINT (values) != s.st_size)
- values = make_int (-1);
I went ahead and fixed the indicated bug. In general, I am not going to
‘document consideration for interaction with desirable future features’ for
every bug fix, and I hope you don’t too.
Who is behaving with "hostility on the collaborative
level," may I ask?
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
XEmacs-Patches mailing list