home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / eiffel / 1020 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.1 KB
  1. Path: sparky!uunet!mcsun!uknet!cf-cm!news
  2. From: SPARKER@CHL.IE ("Simon Parker, Computer consultant")
  3. Newsgroups: comp.lang.eiffel
  4. Subject: How to design a data structure library
  5. Message-ID: <1C20AE2393DF002118@chl.ie>
  6. Date: 28 Jul 92 08:19:00 GMT
  7. Sender: news@cm.cf.ac.uk (Network News System)
  8. Organization: University of Wales College of Cardiff, Cardiff, WALES, UK.
  9. Lines: 41
  10. X-Envelope-To: comp.lang.eiffel@cm.cf.ac.uk
  11. X-Vms-To: IN%"comp.lang.eiffel@cm.cf.ac.uk"
  12. X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway
  13.  
  14.  
  15.  [Reference the discussion on data structure library design, specifically
  16.  the question of list cursors]
  17.  
  18. It seems to me that in some circumstances the complexity of managing
  19. multiple cursors for a list might be avoided by using shallow copies.
  20.  
  21. I'm not sure which variant of 'copy' I mean, but it's the one which
  22. produces a new list and a new set of 'linkables' without copying
  23. the contents.
  24.  
  25. Instead of regarding the list as the shared object and the cursors
  26. as private access mechanisms, think of the list elements as shared
  27. and the list itself as a private access mechanism.
  28.  
  29.  
  30. There are a number of advantages of this approach.
  31.  
  32.  One cursor per list will suffice, preserving the elegance of the
  33.  'active structure' concept.
  34.  
  35.  Each accessor has a full set of list features, including count,
  36.  insert, remove.
  37.  
  38.  Interference between multiple inserters and the philosophical questions
  39.  about versions go away. The corollary, of course, is that a new element
  40.  is only visible to the inserter.
  41.  
  42.  Similarly with deletion - the thing the element references doesn't
  43.  get deleted, it just gets detached from the deleter's list. Again,
  44.  it's still in the other lists.
  45.  
  46.  Modification of an object which appears in multiple lists is arbitrated
  47.  by the object, rather than by the lists or cursors.
  48.  
  49. There are of course disadvantages which make the approach unsuitable
  50. in many circumstances. If a shared list is what you need copies won't
  51. help, and I don't see how this could work with expanded types. It
  52. is easy to find situations in which the advantages turn into disadvantages!
  53.  
  54. Does this have merit, or am I being naive?
  55.