home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / oop / macapp3 / 223 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  8.9 KB
  1. Path: sparky!uunet!stanford.edu!apple!applelink.apple.com
  2. From: GOTTSHALL.R@AppleLink.Apple.COM (Robert Gottshall,GEIS)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Bedrock News
  5. Message-ID: <724520795.6224101@AppleLink.Apple.COM>
  6. Date: 16 Dec 92 15:42:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 202
  10.  
  11. Folks,
  12.  
  13. I got this from a friend on the internet.  Interesting.
  14.  
  15. Rob Gottshall
  16. GEIS
  17.  
  18. ----------------
  19.  
  20. From: felciano@summit.stanford.edu (Ramon M. Felciano)
  21. Subject: News on Bedrock
  22. Date: Wed, 16 Dec 92 06:34:04 GMT
  23.  
  24. Hi all --
  25.  
  26. I just came from a meeting of the Software Entrepreneurs Forum at Apple
  27. where they had a rep from Symantec talking about Bedrock. Nothing
  28. dramatic was revealed (surprise), but it was a sobering experience. I
  29. thought I'd through out some of the salient points I remember.
  30.  
  31. I know you're all dying to hear about this, but I'd like to point out
  32. that (1) this is still subject to change, and (2) I didn't take any
  33. notes, so I may be wrong on some counts -- I'm doing my best :)
  34.  
  35. The first part of the talk was given by an Apple guy who, until
  36. recently, was Apple's rep in the joint venture. The feeling I got from
  37. his slides was that Apple was trying very hard to make it seem like
  38. they were bringing a whole lot to the project, but underneath it all,
  39. it was Symantec who came up with it, Symantec is doing most of the
  40. work, and Symtantec will probably do most of the sales.
  41.  
  42.  
  43. Overview
  44. ========
  45. Bedrock is made up of 3 parts:
  46.  
  47. Class Library
  48. -------------
  49. A C++ class libary which is a mix between MacApp and TCL. MacApp will
  50. continue to get bug fixes, but no new releases. TCL will continue to be
  51. a supported product as Symantec doesn't necessarily see them as being
  52. in competition (probably because of the size of the environment).
  53. Bedrock has alot of TCL similarities (Views, Bureaucrats, and some
  54. others). I think there are about 150+ classes so far. They didn't show
  55. us any details (surprise), but some of the categories included graphics
  56. primitives (lines, arcs), text, and others.
  57.  
  58. I was disappointed that there weren't any obvious facilities for
  59. creating new interface elements (that is, is drag-and-drop as basic a
  60. function under Bedrock as clicking?)
  61.  
  62. While Bedrock does share a large number of similarities between MacApp
  63. and TCL, porting your code will not be a "no-brainer" (their words). It
  64. does seem, however, that TCL has a longer life expectancy than MacApp
  65. as far as continuing development goes...
  66.  
  67. Resource Manager
  68. ----------------
  69. Basically a cross-platform Rez language. Describes visual interface and
  70. (I believe) objects as well. Should let you subclass / dynamically
  71. create new kinds of objects at runtime, although it wasn't quite clear
  72. how this would work.
  73.  
  74. Utilities Manager
  75. -----------------
  76. They made a big deal about how Bedrock was geared towards developing
  77. world-ready software. They've essentially implemented a bunch of
  78. internationalization tools (like 7.1's date and numbers control panels)
  79. to support different languages. These are actually libraries that exist
  80. today and that will have class wrappers around them. Why they don't
  81. simply release them today wasn't quite clear to me :)
  82.  
  83. They didn't talk about the whole Font and Script stuff either.
  84.  
  85. They did mention that they had their own approach to File and Memory
  86. management. The former gives you a common way to refer to files across
  87. platforms; the latter gets you away from these stupid handles (still
  88. pointer based).
  89.  
  90.  
  91. Other notes
  92. ===========
  93. Platforms
  94. ---------
  95. Will initially run on Windows and Mac. UNIX is probably the next
  96. target, but that's a ways off. Should be compilable under MPW and the
  97. (pretty definite although not confirmed) C++ version of THINK C, as
  98. well as Zortech and Microsoft's C environments on the Windows side.
  99.  
  100. Licensing
  101. ---------
  102. They're not clear on how they will approach it. Most everyone agreed
  103. that individual runtime licensing would doom the product. The rep
  104. understood that, but seemed to indicate that the alternative was a 10K
  105. or higher price tag. This met with general grumbles, but no major
  106. protests.
  107.  
  108. Competition
  109. -----------
  110. They currently see their biggest competitor as being XVT. I've got
  111. mixed feelings about this. My roommate has worked extensively with XVT
  112. and says it is the best cross-platform tool currently available, but
  113. the Mac versions that it spits out still look terrible. Since Bedrock's
  114. classes seem to isolate from Quickdraw and the other toolbox goodies
  115. that allow us to make our Mac apps so cool, I'm not to hopeful about
  116. what Bedrock apps look like :(.
  117.  
  118. No mention about Quorum, either. I happen to think Quorum's product is
  119. totally cool, especially since I've actually seen it work.
  120.  
  121. Microsoft
  122. ---------
  123. There was a manager from Microsoft's development tools group there who
  124. reminded us about the Windows for Mac Programmers conference in
  125. January. He seemed quite supportive of Bedrock, as well as any of the
  126. other cross-platform tools: their goal is simply to get as many Windows
  127. apps up as possible.
  128.  
  129.  
  130. Problems
  131. ========
  132. Here's a couple of the problems I saw.
  133.  
  134. Apple Object Model
  135. ------------------
  136. There was no clear support for this within Bedrock, even though Apple
  137. seems to be pushing this as the way to think about and develop
  138. applications. It forces you to implement your program using
  139. well-defined object definitions (the AE suites). This, in turn, makes
  140. you app modular, apple-event savvy, and dying to be script driven. It
  141. is a cool, albeit somewhat foreign, approach to development that is in
  142. danger of being swept under the rug if Bedrock doesn't embrace it.
  143.  
  144. System Software Support
  145. -----------------------
  146. It wasn't clear how Apple's system software would fit into this. There
  147. will definitely be support on the Macintosh side for any new toolboxes
  148. (e.g. Quickdraw GX, OCE), but if a Windows version isn't there at the
  149. same time, what's the point of porting? Yug.
  150.  
  151. A whole new system to learn
  152. ---------------------------
  153. It still seemed like you'd need to learn the Mac toolbox, some windows
  154. stuff, plus the entire 150+ class library. Yich. Contrast this to
  155. Quorum ans some other porting facilities that simply grab the Mac
  156. toolbox and re-implement it on other platforms.
  157.  
  158.  
  159. Soapbox
  160. =======
  161. It really seems that the current approach to OOP isn't delivering its
  162. promises. Eiffel and Smalltalk do better, but they have different
  163. programming environments. Neither of the speakers mentioned any
  164. dramatic changes in the environments we'll be using to program in. The
  165. Apple said that Bedrock sort of tried to fit into the chasm between
  166. Hypercard and C, but I'm not convinced :) My vision of this project is
  167. more along the lines of a blend between a conventional compiled
  168. language and an interpreted language. It seems that many of the
  169. promises of OOP fall apart when forced into a conventional C (or Pascal
  170. or what have you) development environment.
  171.  
  172. A major point of Bedrock is that it is a Framework that basically
  173. implements the functionality that is similar to all Mac programs
  174. (windows, dialogs, buttons, menus, etc. as well as dragging, apple
  175. events, etc.). Well, that was what TCL and MacApp were supposed to be.
  176. The big problem there is that every app you create carries this
  177. Framework around as luggage. It seems to me that there should be a
  178. default application framework that is always active and is part of the
  179. system software. Your application essentially registers itself to the
  180. "application manager" (or some such) and only implements the stuff
  181. specific to your app.
  182.  
  183. Further more, while I support the premise and theories behind OOP, they
  184. really don't fit into a conventional, file-based programming
  185. environment. For example, why do we need to have "includes" or "USES"
  186. clauses in an OOP environment? There should be a big object database
  187. behind the scenes -- we just call up whatever objects we want, and the
  188. extra ones are stripped out at compile time. All files could go away.
  189.  
  190. Furthermore, we should be able to edit and incrementally compile any
  191. particular part of the program, and test it out right away. This is
  192. obviously feasible (check out MCL or some if its offspring).
  193.  
  194. Another place where many of the existing "frameworks" seem to fall
  195. short is blending interface and data objects. It is often awkward to
  196. implement the two separately and link them later on. Ideally, we should
  197. edit the interface by manipulating it directly. Then edit the engine
  198. using a data structure or class hierarchy browser (or some other
  199. visualization device -- an area begging for some good CHI research).
  200. Then link the two by drag-and-drop or drawing lines between the two.
  201.  
  202. Anyway. Enough rambling. Hope this helps some of you somehow. Feel free
  203. to send me mail if you have any questions :)
  204.  
  205. Ramon
  206.  
  207. +----------------------------------------------------------------+
  208. | Ramon M. Felciano                felciano@summit.stanford.edu  |
  209. | Associate Director, SUMMIT       (415) 723-9688                |
  210. | Stanford University Medical Media and Information Technologies |
  211. +----------------------------------------------------------------+
  212.  
  213.