home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / object / 4662 < prev    next >
Encoding:
Text File  |  1992-12-24  |  2.3 KB  |  52 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!spool.mu.edu!wupost!csus.edu!netcom.com!objsys
  3. From: Bob Hathaway <objsys@netcom.com>
  4. Subject: Re: GCC 2.3.2 implementation of signatures for C++
  5. Message-ID: <1992Dec24.225317.26503@netcom.com>
  6. Sender: objsys@netcom.com (Object Systems)
  7. Organization: Object Systems
  8. References: <1h8cg6INNccc@ector.cs.purdue.edu> <1992Dec23.151615.27346@fnbc.com> <1hbojuINNt6u@ector.cs.purdue.edu>
  9. Date: Thu, 24 Dec 1992 22:53:17 GMT
  10. Lines: 40
  11.  
  12. In article <1hbojuINNt6u@ector.cs.purdue.edu> gb@cs.purdue.edu (Gerald Baumgartner) writes:
  13. >  [On adding abstract types to g++]
  14.  
  15. First, I'm glad to see abstract types introduced for widespread use.
  16.  
  17. >A distributed object capability is not done by just adding signatures.
  18. >Our signatures are compile time type definitions.  The compiler uses
  19. >them only for type checking purposes.  At run time, the only type
  20. >information that's available is the signature table (similar to a
  21. >virtual function table).  It is used to dispatch to the correct class
  22. >method.
  23. >
  24. >To allow passing objects in a distributed environment, you need a
  25. >run-time notion of signatures.  And you need to perform type checks
  26. >(i.e., signature conformance checks) at run time when an object is
  27. >sent from one machine to another.
  28.  
  29. In the general case, yes.  But statically not if you have the (remote)
  30. declarations on the sender's side and compile them there.  This appears to
  31. me to be the same distributed or not, with some additional issues in the
  32. non-trivial cases that might come up in object-oriented operating systems
  33. (distributed systems).
  34.  
  35. I don't have the papers with me, but I seem to recall Emerald has abstract
  36. types with static checking *and* distributed object-oriented programming
  37. all in one; I'll have to check.  I also seem to recall that distributed
  38. programming was one of the driving forces behind Emerald's abstract types,
  39. which provide the (at least static) loose coupling called for by
  40. distribution.
  41.  
  42. >There is research done here at Purdue on building a distributed object
  43. >system for a heterogenous programming environment, but this research
  44. >is independent of the signature language construct for C++.  In fact
  45. >it is independent of the programming language.
  46.  
  47. [With hand over heart]
  48. From my old Alma Matter!  Who's doing the work?
  49.  
  50. bob
  51. objsys@netcom.com
  52.