home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 4: GNU Archives / Linux Cubed Series 4 - GNU Archives.iso / gnu / gnu-objc.0 / gnu-objc / class-Nil < prev    next >
Encoding:
Internet Message Format  |  1993-03-01  |  2.9 KB
  1. Date: Mon, 1 Mar 1993 14:00:34 +0100
  2. From: Kresten Krab Thorup <krab@iesd.auc.dk>
  3. To: gnu-objc@gnu.ai.mit.edu
  4. Subject: Introducing class Nil
  5. Cc: krab@iesd.auc.dk
  6.  
  7. Hi again
  8.  
  9. I have been considering the possibility to introduce class Nil as a
  10. full featured class, just as any other class.  Since the special nil
  11. object (currently defined as "(id)0") actually has some object-like
  12. behavior, it would be nice to encapsulate it in a real class.
  13.  
  14. Right now I can think of two actions that is expected from the nil
  15. object:  Ignoring messages send to it, and being able to be stored on
  16. persistent storage.  People on the list could possibly come up with
  17. more `behavior' bound to the nil object.
  18.  
  19. I think of class Nil, as a special class, which has exactly one
  20. instance, the `nilObject'.  For the matter of ignoring messages send
  21. to it, this could be done by overwriting `doesNotRecognize:' to simply
  22. not print any warning.  The messenger should redirect all messages
  23. send to a null pointer to this nilObject.  Like this:
  24.  
  25.   IMP objc_mesgSend(id receiver, SEL operation) 
  26.   {
  27.     if(receiver==0)
  28.       receiver = nilObject;
  29.     return perform_lookup(receiver->class, operation);
  30.   }
  31.  
  32. The messenger will have to handle a null pointer especially anyway, so
  33. this will not cost anything.
  34.  
  35. Another benefit from having a such `nilObject' is that the programmer
  36. could perhaps optionally set a flag indicating weither
  37. `doesNotRecognize:' should actually print a warning message when
  38. invoked.  This would be nice to have when locating bugs.
  39.  
  40. For the matter of storing instances, this will come immediately as a
  41. result of changing the messenger like above -- we will simply define
  42. storeOn: etc methods directly in class Nil.  
  43.  
  44. I think `nil' would still have to be defined as `(id)0', since a lot
  45. of things depend on this.  The only place to take special care about
  46. the nil class would be in the messenger as far as I can se.
  47.  
  48. Other methods which could possibly defined in class nil is `isNil'
  49. like Smalltalk does.
  50.  
  51. I have included a proposed interface for class Nil below.
  52.  
  53. Thanks,
  54.  
  55. Kresten
  56.  
  57. ------------------------------------------------------------
  58.  
  59. extern id nilObject;
  60. extern Class_t nilClass;
  61.  
  62. @interface Nil:Object
  63. {
  64.   BOOL ignoreNilMessages;       /* global flag */
  65. }
  66.  
  67. + new;                          /* allways return `nilObject' */
  68.  
  69. + initialize;                   /* allocate `nilObject' using 
  70.                                    class_createInstance()     */
  71.  
  72. - storeOn: aStream;             /* print a nil object */
  73.  
  74. + catchMessages;                /* set flag indicating if
  75. + ignoreMessages;                  doesNotRecognize: should warn */
  76.  
  77. - doesNotRecognize:(SEL)aSel;   /* ignore or warn as prescribed
  78.                                    by the global flag */
  79.  
  80. - ( BOOL ) isNil;        /* always answers YES */
  81.  
  82. @end
  83.  
  84. @interface Object (isNil)
  85. - ( BOOL ) isNil;        /* always answers NO */
  86. @end
  87.  
  88. ------------------------------------------------------------
  89.  
  90.