home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / oop / misc / 145 < prev    next >
Encoding:
Internet Message Format  |  1992-12-30  |  2.8 KB
  1. Path: sparky!uunet!hayes!bcoleman
  2. From: bcoleman@hayes.com (Bill Coleman)
  3. Newsgroups: comp.sys.mac.oop.misc
  4. Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
  5. Message-ID: <6606.2b41845f@hayes.com>
  6. Date: 30 Dec 92 11:13:35 EDT
  7. References: <1992Dec1.220344.234@physc1.byu.edu> <1992Dec3.064131.23364@reed.edu> <Dec.3.13.57.31.1992.18090@gandalf.rutgers.edu> <1992Dec4.081456.13906@reed.edu> <1992Dec29.213057.14290@news.mentorg.com>
  8. Organization: Hayes Microcomputer Products, Norcross, GA
  9. Lines: 52
  10.  
  11. In article <1992Dec29.213057.14290@news.mentorg.com>, bcohen@scherzo.NoSubdomain.NoDomain (Bruce Cohen) writes:
  12. > Damn! He hit one of my hot buttons!
  13.  
  14. You too!
  15.  
  16. > In fact, you can (or at least should be able to) understand a framework
  17. > without knowing the details of the implementation, or even the syntax of
  18. > the implementing language.  
  19.  
  20. You are correct. At least, in theory. Unfortunately....
  21.  
  22. > A framework is an organization of parts and
  23. > a description of how they work together; 
  24.  
  25. Indeed. And, in the case of MacApp and the TCL, the developers of these
  26. frameworks have only shipped half of the product. They have shipped the parts,
  27. but when it comes to delivering the description -- what little they have
  28. shipped is woefully inadequate. 
  29.  
  30. Take for example the TCL. The shipped a significant number of classes with
  31. the TCL 1.1 for which there is next to no documentation. Sure, there's a
  32. little read.me file that has a brief description of the classes. But no one
  33. at Symantec has bothered to write a description equal to the other classes
  34. that appear in the manual.
  35.  
  36. Part of the problem is the character of the implementation languages used 
  37. for these frameworks -- it isn't entirely the fault of the developers.
  38.  
  39. Until documentation and languages appear that are conducive to producing
  40. concise frameworks, we'll have to continue to struggle along with wading
  41. through the source code.
  42.  
  43. > In many situations all
  44. > you really *need* (as opoposed to what you might want to have) to write
  45. > an overriding method in a subclass is the signature of the method and
  46. > a set of assertions which describe the pre- and post-conditions for the
  47. > method.  Sure it's easier if you have some code to look at and maybe
  48. > reuse, but you could do without that.
  49.  
  50. Sounds like you are suggesting people build frameworks in Eiffel, which
  51. has formal mechanisms for defining pre and post conditions for all routines.
  52.  
  53. Too bad there isn't such an Eiffel implementation for the Mac.
  54.  
  55. -- 
  56. Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
  57. Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
  58. Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
  59. POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
  60. Disclaimer: "My employer doesn't pay me to have opinions."
  61. Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
  62.  
  63.