home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.30 / text0016.txt < prev    next >
Encoding:
Text File  |  1993-03-11  |  1.9 KB  |  41 lines
  1. Submitted-by: preece@urbana.mcd.mot.com (Scott E. Preece)
  2.  
  3. The problem is that in the current environment saying "Don't make us
  4. write test methods" really means "We think it's better to send the
  5. standard our a little half-baked than to take the time to remove another
  6. round of ambiguities."  That *may* be the right answer.  It may very
  7. well be that more ambiguities will be exposed and interpreted by getting
  8. the standard out for people to implement.  On the other hand, it also
  9. may be that each implementor will guess and interpret when faced with
  10. ambiguity, rather than seeking interpretation through inconvenient and
  11. possibly slow official channels.
  12.  
  13. What is important about the test method requirement is that it requires
  14. the standard writers to translate the specification into another form.
  15. There is no structural guarantee that the alternative form will be
  16. complete or perfect, but there is a high probability that *some*
  17. ambiguities will be exposed.
  18.  
  19. My experience with trying to get a system to meet a standard that was
  20. intended to be quite unambiguous (the 88000 version of the SVR4 ABI) is
  21. that none of the existing standards is there yet and that forcing the
  22. authors to think about them a little longer and in a different form is
  23. for the good, though I must also acknowledge that I don't know how my
  24. own work group is going to get that work done, either.
  25.  
  26. If we can't keep our people and our companies interested, we're going to
  27. be stuck with one unambiguous standard: what runs successfully on NT on
  28. the architecture whose name I prefer to leave unuttered...  I think that
  29. would be for the worse, and I hope I would feel that way even if it were
  30. our architecture that were the common reference.
  31.  
  32. --
  33. scott preece
  34. motorola/mcg urbana design center    1101 e. university, urbana, il   61801
  35. uucp:    uunet!uiucuxc!udc!preece,     arpa:    preece@urbana.mcd.mot.com
  36. phone:    217-384-8589              fax:    217-384-8550
  37.  
  38.  
  39. Volume-Number: Volume 30, Number 17
  40.  
  41.