home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / oop / macapp3 / 202 < prev    next >
Encoding:
Internet Message Format  |  1992-12-15  |  4.7 KB
  1. Path: sparky!uunet!hayes!bcoleman
  2. From: bcoleman@hayes.com (Bill Coleman)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re: RE>MacApp demo code ?
  5. Message-ID: <6547.2b2df22f@hayes.com>
  6. Date: 15 Dec 92 14:56:47 EDT
  7. References: <724322275.6320755@AppleLink.Apple.COM>
  8. Organization: Hayes Microcomputer Products, Norcross, GA
  9. Lines: 94
  10.  
  11. In article <724322275.6320755@AppleLink.Apple.COM>, BERDAHL@AppleLink.Apple.COM (Taligent, Eric Berdahl,PAS) writes:
  12. >  
  13. > But before I go on with that discussion, let's set some facts straight.
  14. >  
  15. > First off, I don't believe that Apple ever announced OSL support for MacApp.
  16. > They kept talking like there would be a 3.1, and that it would have Object
  17. > Model support, but they were very careful not to make a clear commitment. That
  18. > was one of the more annoying things about this whole mess is that they would
  19. > never say what they would do other than think about it. Meanwhile, developers
  20. > are left hanging in the breeze.
  21.  
  22. You may be technically correct about Apple making an announcement. Surely, they
  23. showed intent openly to developers.
  24.  
  25. At the last developers conference, I repeatedly quizzed Tom Chavez, and he
  26. assured me that OSL support would be in the next release of MacApp. I felt
  27. that while MacApp 3.0 was a step forward, support for all the new system
  28. features was desparately needed.
  29.  
  30. We agreed that it wasn't necessarily MacApp's intent to replace the toolbox.
  31. So, for some system features, no "MacApp support" was really necessary. 
  32. Developers could simply call the toolbox in their appropriate methods.
  33.  
  34. However, some system features really needed to be worked into the framework.
  35. OSL is one of them. 
  36.  
  37. I also got somewhat frustrated at the developer's conference where Apple would
  38. repeatedly state that developers should use MacApp for new development, but
  39. when presenting information on new technologies, MacApp support was no where
  40. in sight. (Witness: AppleScript, QuickDraw GX) 
  41.  
  42. The technology teams claimed that such integration was the responsibility of
  43. the MacApp team. The MacApp team screamed that they couldn't possibly keep
  44. up with all the technology being developed.
  45.  
  46. Obviously, proper management and cooperation inside Apple is missing. Both
  47. teams should have worked together to mutually support both the technology and
  48. the framework.
  49.  
  50. Then in June, the bomb dropped, leaving developers without a satisfactory
  51. development framework for the forseeable future. 
  52.  
  53. IMHO, Apple has really bumbled this one. It would have been one thing to
  54. support Bedrock when it was ready to ship. But cutting MacApp off at the
  55. knees in a half finished state wasn't very smart. And Bedrock may still
  56. be a year or more off. Who knows? Symantec isn't saying. All Apple developers
  57. can do is plod along and wonder what is going to happen, and whether they should
  58. switch over to doing Windows development. (bleah)
  59.  
  60. > Second, the unsupported unit would never have worked. That was one of the
  61. > central points of my presentation at MADACON '92: that you need underlying
  62. > architectural support for scripting concepts, they can't be just pasted onto
  63. > an application or a framework.
  64.  
  65. Indeed. These are the sorts of things that should have been worked into 
  66. MacApp 3.0 when it first shipped.
  67.  
  68. > Why should you write MacApp code when even I wrote an article about object
  69. > programming without mentioning MacApp? There are lots of reasons. MacApp is
  70. > the best class library available today for doing Macintosh development.
  71. > Period. 
  72.  
  73. Agreed. Even MacApp 2.0 is good.
  74.  
  75. Isn't it a shame that Apple has chopped off development and is only providing
  76. minimal (life) support to MacApp?
  77.  
  78. > Since MacApp has a rich library of classes that
  79. > should be providing default Object Model behavior, just adding the mechanics
  80. > are not enough. Instead, you will probably find yourself compelled to add such
  81. > behavior to MacApp itself, out of a sense of indignity at Apple forgetting
  82. > such a vital part of the architecture. 
  83.  
  84. Since Apple should have obviously provided this, we developers wonder why
  85. they didn't. That and the fact that repeated promises that they would
  86. support this doesn't sit well.
  87.  
  88. > Well, anyways, I hope that helps clear things up. Is MacApp dead? That's a
  89. > silly question. Of course it isn't. 
  90.  
  91. MacApp isn't dead, but it is in the ICU, on minimal life support.
  92.  
  93. > It is stagnant? Only the future will decide that.
  94.  
  95. It is hard to have much of a future when you are on life support....
  96.  
  97.     -- 
  98. Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
  99. Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
  100. Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
  101. POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
  102. Disclaimer: "My employer doesn't pay me to have opinions."
  103. Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.
  104.  
  105.