home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / objectiv / 691 < prev    next >
Encoding:
Internet Message Format  |  1992-12-14  |  2.6 KB

  1. Path: sparky!uunet!casey!gaboon!seltd!lerman
  2. From: lerman@seltd.UUCP (Kenneth Lerman)
  3. Newsgroups: comp.lang.objective-c
  4. Subject: Re: Advice on accepting/returning objects vs. copies of objects
  5. Message-ID: <29@seltd.UUCP>
  6. Date: 10 Dec 92 22:36:22 GMT
  7. References: <1992Dec7.212541.20646@colorado.edu>
  8. Reply-To: lerman@seltd.UUCP (Kenneth Lerman)
  9. Distribution: usa
  10. Organization: Systems Essentials Limited
  11. Lines: 55
  12.  
  13. In article <1992Dec7.212541.20646@colorado.edu> fedor@hopper.Colorado.EDU (Adam Fedor) writes:
  14. |I think I have an answer to this, but since I'm very new to Obj-C, I thought
  15. |I'd ask:
  16. |
  17. |Say I have an instance of a class List (myList) that stores a 
  18. |bunch of objects.  If some
  19. |client asks for an object and myList returns it, instead of a copy 
  20. |of the object, this leaves open the possibility that the client may 
  21. |change and/or even free the object without myList knowing about - with
  22. |disasterous consequences.
  23.  
  24. You are correct that the client may free the object.  Whether the
  25. consequences are disasterous or not depends on the intent of the
  26. creater of the list.
  27.  
  28. It is a matter of policy (which may vary from usage to usage) of "who"
  29. owns an object which is "contained" in another object.  In the case of
  30. container classes (like Stepstone's OrdCltn and, I assume, List) the
  31. ownership is left up to the user.
  32.  
  33. |
  34. |I suspect that you should make a copy of any object that is accepted/returned.
  35. |This also jives with the theory that data within an object (including other
  36. |objects) should not be accessable to the outside.
  37. |
  38.  
  39. While the policy you suggest here is very simple to understand, it has
  40. two major disadvantages:
  41.  
  42. 1 -- It has the high overhead of making multiple copies of everything.
  43.  
  44. 2 -- Sometimes you want a client to be able to make changes to an
  45. object.  Consider the case of a List which is used to hold the members
  46. of a family.  If I want to change the profession of one of the
  47. members, I would first find the member in the List.  But under your
  48. policy, this would give me a copy.  If I then changed the profession
  49. of the member and printed the list, I would still get the old profession.
  50.  
  51. ...Not to be confused with the oldest profession... :-)
  52.  
  53. |However, I have to be sure that all objects I accept/return implement a
  54. |deepCopy or I might get other unwanted effects.
  55. |
  56. |Any thoughts on this?  Thanks.
  57.  
  58. |
  59. |Adam Fedor. CU, Boulder            | Fudd's Law of Opposition: Push something  
  60. |fedor@boulder.colorado.edu (W)      |   hard enough and it will fall over. 
  61. |adam@bastille.rmnug.org (H,NeXTMail)|
  62.  
  63. -- 
  64. Kenneth Lerman                  ...!uunet!casey!gaboon!seltd!lerman
  65. Systems Essentials Limited                            (203)426-4430
  66. 55 Main Street
  67. Newtown, CT 06470
  68.