home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / mac / oop / macapp3 / 237 < prev    next >
Encoding:
Text File  |  1992-12-21  |  2.6 KB  |  62 lines
  1. Newsgroups: comp.sys.mac.oop.macapp3
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!data.nas.nasa.gov!taligent!lsr.taligent.com!user
  3. From: lsr@taligent.com (Larry Rosenstein)
  4. Subject: Re: Bedrock News
  5. Message-ID: <lsr-181292121530@lsr.taligent.com>
  6. Followup-To: comp.sys.mac.oop.macapp3
  7. Sender: usenet@taligent.com (More Bytes Than You Can Read)
  8. Organization: Taligent, Inc.
  9. References: <724520795.6224101@AppleLink.Apple.COM>
  10. Date: Fri, 18 Dec 1992 20:23:26 GMT
  11. Lines: 49
  12.  
  13. In article <724520795.6224101@AppleLink.Apple.COM>,
  14. GOTTSHALL.R@AppleLink.Apple.COM (Robert Gottshall,GEIS) wrote:
  15. > 
  16. > It really seems that the current approach to OOP isn't delivering its
  17. > promises. Eiffel and Smalltalk do better, but they have different
  18. > programming environments. Neither of the speakers mentioned any
  19.  
  20. Bedrock was not intended to address the programming environment issue. 
  21. There is a lot of work going on in terms of C++ progamming environments in
  22. the Unix market (from ParcPlace, HP, Sun, Lucid, etc.) and there's
  23. Component Workshop in the Mac market.  
  24.  
  25. My understanding is that Bedrock was designed to work with any C++
  26. compiler, and so it could be used in any of these environments.  (Assuming
  27. CW does enough of C++, which I'm not clear about.)
  28.  
  29. > Apple said that Bedrock sort of tried to fit into the chasm between
  30. > Hypercard and C, but I'm not convinced :) My vision of this project is
  31.  
  32. I wouldn't be convinced either.  HyperCard and C are totally different
  33. things.  Even if he meant HyperTalk and C, those are languages and Bedrock
  34. in a framework.
  35.  
  36. > events, etc.). Well, that was what TCL and MacApp were supposed to be.
  37.  
  38. The difference is that Bedrock was designed to be cross-platform, while TCL
  39. and MacApp were not.
  40.  
  41. > Framework around as luggage. It seems to me that there should be a
  42. > default application framework that is always active and is part of the
  43. > system software. Your application essentially registers itself to the
  44.  
  45. That's a good point, but I think it's a third orthogonal point.  In theory,
  46. there's no reason why Bedrock (or MacApp for that matter) couldn't be
  47. shared among apps.
  48.  
  49. > environment. For example, why do we need to have "includes" or "USES"
  50. > clauses in an OOP environment? There should be a big object database
  51.  
  52. This is where the C++ environments I mentioned are heading.  Certainly
  53. Component Workshop does something like this, and I think the others may do
  54. this as well.  But I don't think it's a framework issue, although when you
  55. consider the entire task of creating an application you need all these
  56. pieces (development environment, frameworks, shared libraries).
  57.  
  58. Larry Rosenstein
  59. Taligent, Inc.
  60.  
  61. lsr@taligent.com
  62.