home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / misc / 22994 < prev    next >
Encoding:
Text File  |  1992-12-13  |  2.7 KB  |  56 lines

  1. Newsgroups: comp.sys.next.misc
  2. Path: sparky!uunet!microsoft!hexnut!edwardj
  3. From: edwardj@microsoft.com (Edward Jung)
  4. Subject: Re:   Why, Why, WHYYYY?? USE OBJECTIVE-C for IB??
  5. Message-ID: <1992Dec13.100829.27279@microsoft.com>
  6. Date: 13 Dec 92 10:08:29 GMT
  7. Organization: Strategy Division, Microsoft Corp.
  8. References: <dillon.0s9m@overload.Berkeley.CA.US> <1992Dec7.122138.389@uunet!cbmvax!xmws!kripalu> <dillon.0sh6@overload.Berkeley.CA.US>
  9. Lines: 45
  10.  
  11. Matthew Dillon writes:
  12.  
  13. >    I should mention that a strong run-time system cannot be optimized
  14. >    easily (or at all) whereas a strong compile-time and load-time system
  15. >    can both be optimized AND handle interface portability concerns without
  16. >    any run-time system getting in the way, but that generally entails
  17. >    building part of the compiler into every machine to handle
  18. >    'installation' (integration) of an application.  C++ has yet to reach
  19. >    this capability and may never do so as it insists, as most languages
  20. >    do, on sticking to a strict compile time paradigm.
  21.  
  22. In fact I would argue that the interface run-time should be
  23. completely language-independent as well as very fast. As Matthew
  24. points out, a compile and load oriented system such as fast
  25. RPC interfaces is advantageous. What this means is that in
  26. local bindings between code and an externally-supplied module
  27. (or "software IC"), the performance hit can be as small as
  28. a single register or memory indirection -- less if you are
  29. willing to do relocation on load (just depends where you want
  30. to spend your CPU cycles and when). When you go cross-machine,
  31. you convert to a messaging system using standard RPC techniques.
  32.  
  33. Objective-C and the NeXT run-time always use messaging, and
  34. perform language-specific optimizations for in-process
  35. invocation. The messaging system also brings synchronization
  36. issues in multi-threaded environments since the message 
  37. encapsulates synchronization semantics whereas compiler
  38. invocations do not. The developer that therefore writes
  39. a software component must use messaging, think about
  40. thread safety in the client run-time, and therefore
  41. worry about distribution transparency (i.e. where the
  42. component code runs).
  43.  
  44. Issues such as how to write a reusable and distributable
  45. component should really not be addressed in a language.
  46. They should be addressed as an infrastructure for an object
  47. system that is language independent. Then you can worry
  48. about language bindings and new languages that are semantically
  49. identical to the object system's model. It is hard to imagine,
  50. esp. given the religion on languages, that any one language
  51. will meet all needs.
  52.  
  53. --
  54. Edward Jung, Software Architect     edwardj@microsoft.com
  55. Advanced Systems, Microsoft Corp.
  56.