home *** CD-ROM | disk | FTP | other *** search
/ OpenStep 4.2J (Developer) / os42jdev.iso / NextDeveloper / Source / GNU / gcc / objc / README < prev    next >
Text File  |  1995-05-15  |  4KB  |  98 lines
  1.  
  2. GNU Objective C notes
  3. *********************
  4.  
  5. This document is to explain what has been done, and a little about how
  6. specific features differ from other implementations.  The runtime has
  7. been completely rewritten in gcc 2.4.  The earlier runtime had several
  8. severe bugs and was rather incomplete.  The compiler has had several
  9. new features added as well.
  10.  
  11. This is not documentation for Objective C, it is usable to someone
  12. who knows Objective C from somewhere else.
  13.  
  14.  
  15. Runtime API functions
  16. =====================
  17.  
  18. The runtime is modeled after the NeXT Objective C runtime.  That is,
  19. most functions have semantics as it is known from the NeXT.  The
  20. names, however, have changed.  All runtime API functions have names
  21. of lowercase letters and and underscores as opposed to the
  22. `traditional' mixed case names.  
  23.     The runtime api functions are not documented as of now.
  24. Someone offered to write it, and did it, but we were not allowed to
  25. use it by his university (Very sad story).  We have started writing
  26. the documentation over again.  This will be announced in appropriate
  27. places when it becomes available.
  28.  
  29.  
  30. Protocols
  31. =========
  32.  
  33. Protocols are now fully supported.  The semantics is exactly as on the
  34. NeXT.  There is a flag to specify how protocols should be typechecked
  35. when adopted to classes.  The normal typechecker requires that all
  36. methods in a given protocol must be implemented in the class that
  37. adopts it -- it is not enough to inherit them.  The flag
  38. `-Wno-protocol' causes it to allow inherited methods, while
  39. `-Wprotocols' is the default which requires them defined.
  40.  
  41.  
  42. +initialize 
  43. ===========
  44.  
  45. This method, if defined, is called before any other instance or class
  46. methods of that particular class.  This method is not inherited, and
  47. is thus not called as initializer for a subclass that doesn't define
  48. it itself.  Thus, each +initialize method is called exactly once (or
  49. never if no methods of that particular class is never called).
  50. Besides this, it is allowed to have several +initialize methods, one
  51. for each category.  The order in which these (multiple methods) are
  52. called is not well defined.  I am not completely certain what the
  53. semantics of this method is for other implementations, but this is
  54. how it works for GNU Objective C.
  55.  
  56.  
  57. Passivation/Activation/Typedstreams
  58. ===================================
  59.  
  60. This is supported in the style of NeXT TypedStream's.  Consult the
  61. headerfile Typedstreams.h for api functions.  I (Kresten) have
  62. rewritten it in Objective C, but this implementation is not part of
  63. 2.4, it is available from the GNU Objective C prerelease archive. 
  64.    There is one difference worth noting concerning objects stored with
  65. objc_write_object_reference (aka NXWriteObjectReference).  When these
  66. are read back in, their object is not guaranteed to be available until
  67. the `-awake' method is called in the object that requests that object.
  68. To objc_read_object you must pass a pointer to an id, which is valid
  69. after exit from the function calling it (like e.g. an instance
  70. variable).  In general, you should not use objects read in until the
  71. -awake method is called.
  72.  
  73.  
  74. Acknowledgements
  75. ================
  76.  
  77. The GNU Objective C team: Geoffrey Knauth <gsk@marble.com> (manager),
  78. Tom Wood <wood@next.com> (compiler) and Kresten Krab Thorup
  79. <krab@iesd.auc.dk> (runtime) would like to thank a some people for
  80. participating in the development of the present GNU Objective C.
  81.  
  82. Paul Burchard <burchard@geom.umn.edu> and Andrew McCallum
  83. <mccallum@cs.rochester.edu> has been very helpful debugging the
  84. runtime.   Eric Herring <herring@iesd.auc.dk> has been very helpful
  85. cleaning up after the documentation-copyright disaster and is now
  86. helping with the new documentation.
  87.  
  88. Steve Naroff <snaroff@next.com> and Richard Stallman
  89. <rms@gnu.ai.mit.edu> has been very helpful with implementation details
  90. in the compiler.
  91.  
  92.  
  93. Bug Reports
  94. ===========
  95.  
  96. Please read the section `Submitting Bugreports' of the gcc manual
  97. before you submit any bugs.
  98.