R. Clayton (rclayton@clayton.cs.monmouth.edu)
(no date)
In Story 1 you have changed the name of the application from "mailstrip" to
"mail-strip"
Not a significant change. The name of the program should not even appear in
the code.
In Story 2 you specify that the program should terminate with an error if
attachdir does not exist, I think that it is a better application if the
directory is created if it does not exist.
I agree; however, the correct and secure manipulation of directories in unix is
non-trivial and I didn't want people to get bogged down in the minutiae of unix
directory hacking. Also, replacing "abort on absence" code with "make absent
directory" code should be easy to do if your code is well structured.
In Story 3 you specify that the rename function use the suffix "-nn" to
rename the files. I think it is more pleasing aesthetically and more in
keeping with Unix traditions to use .number as the suffix. Also your suffix
limits the number of files of the same name to 99. It would be better not to
have this limitation.
Not a significant change. If you can format it one way, you can format it
another way. And you're always going to have to deal with wrap-around, no
matter how big the version number is.
You also specify that rename will always concatenate a suffix. This leaves
out the plain unsuffixed filename, which is perhaps not really a good thing.
I don't understand this one.
Story 4 - You are going into implementation details here and constraining the
function to be written in C++. This is implied by the signature you
give. What about C language? How about a Shell Script?
That's my prerogative as a customer. As a developer (or requirements analyst)
it's your job to make sure the customer doesn't unnecessarily over-constrain
the solution by specifying implementation details (note that "over-constrain").
As a customer I feel I am justified in constraining the interface between two
subsystems to insure compatibility between existing and potential
attachment-comparison functions. As a developer I feel the interface
constraint is reasonable and will meet the customer's compatibility objective
(which is not to say that it's the only way or even the best way).
As for constraining the implementation language, I don't see that. I've used
c++ to specify the prototype (that is, the interface) because everybody is
(should be) familiar with c++ and it's a reasonably good language for
specifying simple interfaces. Nothing in the prototype prevents you from
implementing the interface in c or shell or anything else. What it does do is
prevent you from implementing an interface that looks like this:
extern char * f1, * f2;
void compare(int & same) { . . . }
Some languages make it harder to demonstrate that you've implemented the
interface correctly than do other languages. If you implement in c++ all you
have to do is show a clean compile (assuming you use a standards compliant
compiler); if you use c or shell you have to do considerably more work to
demonstrate (and maintain) the correct interface.
This archive was generated by hypermail 2.0b3 on Thu Aug 02 2001 - 12:45:05 EDT