home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 596 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  4.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!apple!applelink.apple.com
  2. From: D3085@AppleLink.Apple.COM (Progressive Computing, D Lucky,PRT)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re2: Defections from BedRock?
  5. Message-ID: <727844853.5287057@AppleLink.Apple.COM>
  6. Date: 24 Jan 93 02:53:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 70
  10.  
  11. "Templates I can live without [macros will do for now] but exceptions
  12. would really make my coding life easier."
  13.  
  14. I also feel that built-in exception handling is more important that templates
  15. but, as a library developer, I would really like to have both.  I can kludge my
  16. way around not having these by providing front-end functions for constructors
  17. (for exception handling) and macros (for templates).  For library code, this
  18. creates yet another level of complexity for users of the library that just
  19. isn't necessary.  There's also an issue of whether front-ends for all
  20. constructors in a library should be created.  If not, users may get confused
  21. about which way to create their objects and will likely spend time chasing down
  22. more bugs in their program that should not have been there in the first place.
  23. These are probably expensive bugs since they may not be uncovered until the
  24. product has actually shipped.  If front-ends are provided for a library (and
  25. that could be a lot of unnecessary work itself), then how about the
  26. constructors for the other libraries that someone may want to use for their
  27. program?  The case I'm trying to build is that all of this confusion is really
  28. not necessary with exception handing built into the compiler.
  29.  
  30. Templates would also be very helpful to library developers that provide
  31. collection-type classes.  One interface to a particular type of collection
  32. class is all that is needed with templates.  Users can then instantiate these
  33. collection classes using whatever types they want.  The alternatives are to get
  34. the library developer or the application programmer to either create derived
  35. collection classes for each type the application programmer wants the
  36. collection to contain or to create a macro to do the same thing.  The template
  37. option is much simpler and consistent from both the library developer and
  38. client points of view.
  39.  
  40. Is there a technical reason why exceptions and templates have not been built
  41. into the MPW C++ compiler?  I hear the ANSI committee has completed the
  42. specifications.  I would suspect that AT&T has already built these into a
  43. CFront that they have laying around somewhere.  What gives?  Is Apple going to
  44. move to adopt the ARM or ANSI in its C++ compiler?
  45.  
  46. ...climbing higher on soapbox...
  47.  
  48. Software engineering is very, very expensive these days.  The types of programs
  49. that we create are much more complex than even a few years ago.  With more
  50. powerful hardware just over the horizon, I see these problems getting worse
  51. instead of better.  While the current programming tools are better than they
  52. used to be, I think we need a fundamental change (egad) in the way we develop
  53. software if we want to meet our customers expectations.  This means developing
  54. more complex software that does what the user wants, is very reliable, and is
  55. less expensive that it is today.  We can use assemblers and low-level debuggers
  56. to create "insanely great" products but the cost is very high.  We can use more
  57. integrated object-oriented techniques and development environments that contain
  58. editors, object-oriented programming tools (i.e., compilers, linkers), and
  59. debuggers.  Even then, we have problems managing the complexity and reliability
  60. without huge budgets, long testing periods, and maintenance releases that
  61. contain bug fixes.
  62.  
  63. We need better ways to get from user requirements to finished product reliably
  64. and quickly.  We need integrated tools that track these requirements and allow
  65. us to create solutions that, in turn, generate working programs.  The solution
  66. part of the system would help us manage the complexities of the program from
  67. concept to code.  We should be able to deal with the solution at whatever level
  68. of abstraction that we want.  This would help people to learn existing systems
  69. easier.  We should have tools at the low-level that help prove that the
  70. software is reliable.  Does something like this exist anywhere or is anyone
  71. working on something that does these things?  If not, does it seem worthwhile?
  72. Am I off in the weeds?  My guess is that a lot of the technology for these
  73. things already exist but not in an integrated form.  This may not be the forum
  74. to discuss these sort of things.  If not, where could this discussion be moved?
  75.  
  76. ...climbing down from soapbox...
  77.  
  78. Dave Lucky
  79. Progressive Computing, Inc.
  80.  
  81.