home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / object / 4603 < prev    next >
Encoding:
Text File  |  1992-12-21  |  4.7 KB  |  95 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!torn!nott!cunews!cunews!knight
  3. From: knight@mrco.carleton.ca (Alan Knight)
  4. Subject: Re: Object hidden state and side effects
  5. Message-ID: <knight.724800436@cunews>
  6. Sender: news@cunews.carleton.ca (News Administrator)
  7. Reply-To: knight@mrco.carleton.ca (Alan Knight)
  8. Organization: Carleton University
  9. References: <BzBC1L.3GJ@inews.Intel.COM> <1992Dec15.201242.8995@midway.uchicago.edu> <BzF6uA.1u3@inews.Intel.COM> <1992Dec17.221333.3023@midway.uchicago.edu>
  10. Date: Sat, 19 Dec 1992 21:27:16 GMT
  11. Lines: 84
  12.  
  13. >In article <BzF6uA.1u3@inews.Intel.COM> bongalon@tcad05.intel.com (Ben Bongalon) writes:
  14. >>
  15.  
  16. >Seems to me like we've gone around enough to realize that we're all finally
  17. >talking about the same thing, just from different views.  Now that we've
  18. >got our respective terminologies agreeing, I feel like it's time for a 
  19. >blatant try at closing the discussion.
  20.  
  21. >Values can be indirectly implemented as objects. The only benefit of this 
  22. >(and yes, it's a large one) is that languages do not require two separate 
  23. >semantic constructs for two somewhat related mental constructs.  The direct 
  24. >costs of this is that in current languages this implementation is not quite 
  25. >safe, and requires unenforced coding restrictions to ensure that values really 
  26. >act as values.  This is a known bug source, and should be approached as one.  
  27. >A possible indirect cost is that it places one further interpretation step
  28. >between a programmer's design and her implementation. As decreasing the 
  29. >design/implementation distance is one of object oriented programming main
  30. >strengths, this should be considered accordingly.  Given these costs and
  31. >benefits, I believe that a language could fruitfully be designed which supports
  32. >values and objects as separate concepts.  The costs and benefits probably don't
  33. >justify writing a new language to specifically test this hypothesis, and 
  34. >certainly don't justify increasing the complexity of already overly complex
  35. >languages (C++, Eiffel, and Ada in particular).  But if you just happen to find
  36. >yourself designing a new language which uses some OO concepts and extends
  37. >them with other semantic modelling capabilities (relations, in my case), then
  38. >it's probably worth trying them out.  If it pays off, it's part of the 
  39. >benefits of breaking new ground.  
  40.  
  41. I can agree with most of this, but of course I have to add my two cents. 
  42.  
  43. I agree entirely with Ralph Johnson that adding just the ability to
  44. distinguish values and objects is completely inadequate, and that a
  45. more comprehensive approach to describing code semantics is required.
  46. Given that you seem to be attempting to design a next-generation
  47. language, by all means explore this.
  48.  
  49. As far as the particular question of objects and values is concerned,
  50. there are really two separate issues which I think are orthogonal: the
  51. presence of an identity operation separate from equality and
  52. mutability. We get four classes of things, which I'm going to call by
  53. the names that have been used in this discussion, even if I don't
  54. think they're entirely appropriate.
  55.  
  56. Mutable objects: Have an identity operation, can be modified.
  57. The default case of objects.
  58.  
  59. Immutable objects: Have no operations which modify state, but have an
  60. identity operation. e.g. non-mutable strings
  61.  
  62. Values: Have no operations which modify state, have no identity
  63. operation. e.g. numbers
  64.  
  65. Normal storage (or mutable values): State can be modified, but there
  66. is no identity operation. e.g. storage allocated on the stack in
  67. traditional languages. 
  68.  
  69. I think it is better not to have an identity operation at all for
  70. things for which it doesn't make sense. The alternative would be to
  71. have an identity operation which just calls the equality test, but I
  72. don't think this is as good.
  73.  
  74. Normal object-oriented languages (by which I mean Smalltalk, since
  75. it's what I use normally :-)) can handle objects and immutable objects
  76. (barring cheating with the reflective facilities). It cannot handle
  77. removing the identity operation, particularly since it cheats on this
  78. operation (does not really send a message). This is probably worth
  79. looking at if you are designing a new language. I wonder if Self would
  80. be able to do this...
  81.  
  82. For all of these, the equality operation must be user-defined
  83. (contrary to somebody's earlier assertion that objects use identity
  84. for equality).  Equality can be quite a complex operation. For
  85. example, under IEEE standard arithmetic, there are floating point
  86. numbers which are represented by identical bits, but are not equal
  87. (Nan).
  88.  
  89.  
  90. -- 
  91.  Alan Knight  knight@mrco.carleton.ca  +1 613 788 2600x1027 
  92.  Dept. of Mechanical and Aerospace Engineering              
  93.  Carleton University, Ottawa, Ontario, Canada, K1S 5B6      
  94.  
  95.