home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2460 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  3.3 KB
  1. Path: sparky!uunet!stanford.edu!agate!ucbvax!efftoo.boeing.com!crispen
  2. From: crispen@efftoo.boeing.com (crispen)
  3. Newsgroups: comp.lang.ada
  4. Subject: Retracting yet another unintentional flame
  5. Message-ID: <9208262123.AA22664@efftoo.boeing.com>
  6. Date: 26 Aug 92 21:23:15 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 59
  10.  
  11. I received an email from Joe Wisniewski (which I wish he'd post to the
  12. group) indicating that I had unintentionally sprouted another flame:
  13.  
  14. >And if you're using a flat pure-OOD style where everybody can call everybody >else, you might be hosed, too.
  15.  
  16. I was absolutely *not* saying that this kind of architecture is "good" or
  17. "bad".  I was attempting to say that designs in which types are
  18. mostly declared in specs containing the subprograms that operate on
  19. the types AND in which instantiations of these types are flowing
  20. back and forth between multiple packages, will probably have a
  21. greater number of files to recompile than other kinds of designs.
  22.  
  23. Note that neither side of the AND is a bad architecture, IMHO.
  24. I have used them both (the former much more than the latter) and have
  25. not felt guilty afterwards.
  26.  
  27. I am not even saying that ANDing the two together is a bad idea (though
  28. if someone else were to say so, I would probably not write anything to
  29. rebut them).  The *only* issue I want to raise is the necessity for
  30. recompilation.
  31.  
  32. If someone else wants to say that frequent recompilation of lots of
  33. files is symptomatic of a deeper problem which should have been solved
  34. in design, I will stay right out of that fight.
  35.  
  36. What I *will* assert is that the hierarchical directory structure I
  37. showed in an earlier post maps pretty well to the software architecture
  38. in a particular domain I'm interested in (i.e., I actually used this
  39. directory structure on a program or two).
  40.  
  41. In fact, it may map to that domain so well that it might not be as useful
  42. in other domains.  It occurs to me that creating a directory structure
  43. that maps to the software architecture you employ on a program is a
  44. pretty worthwhile activity.
  45.  
  46. While I'm apologizing for things, I received a note from TeleSoft
  47. indicating that compiling on a Sun certainly does NOT imply that
  48. you're using Verdix.  I do not believe that the person from TeleSoft
  49. will mind if I repeat here his assertion that their compiler allows for
  50. the local libraries that I mentioned as a "good thing" in my earlier
  51. posting.
  52.  
  53. I also understand that some people may be sensitive about the use or
  54. abuse of "types packages".  Please consider this another domain-specific
  55. issue.  I am certainly not asserting that types packages are either
  56. good things or bad things to have.  I think that there are some domains
  57. in which it is very useful to have access to the types defining the output
  58. interfaces of some component without having to take the operations on
  59. those interfaces along with them.  I also think it's useful to define
  60. frequently-used record types (e.g., position or velocity vectors)
  61. and program-specific substitutes for package Standard types without
  62. having to specify in the same place all the operations that
  63. might be performed on objects of those types.  In fact, defining all
  64. the operations that might be performed on objects of type Normalized
  65. might be beyond my current skills.  But that's just me.  Live and let
  66. live.
  67.  
  68. Bob Crispen
  69. crispen@foxy.boeing.com
  70.