kim@helios.enea.se (Kim Wald`n) (04/06/90)
In article <253@eiffel.UUCP> bertrand@eiffel.com (Bertrand Meyer) writes: > I think I finally see what the problem is. (One should > not despair of the human race; just give people time and > they will understand.) I think the consistency of the name system in a library as complicated as the Data Structure library is _extremely_ important, and I am a great fan of the somewhat unorthodox naming convention adopted in Eiffel 2.2. However, since we are sacrificing familiar names of well-known data structures (upsetting quite a few people) in order to capture commonality on a higher level which would otherwise not be there, it is all the more important that the new names have a strong consistent semantic connotation. Accessing an element (``item''), and removing an element (``remove'') do not seem to present any problems. ``Remove'' is perhaps a bit long, but in most applications it is not such a common operation (the only alternative short name that Rodale's Synonym Finder could come up with is ``drop''). However, the distinction between inserting an element and replacing an element was accidentally blurred in the current Data Structure library, which was first pointed out by Bob Weiner. Your proposed solution to use ``put'' for replacing and ``add'' for inserting an element seems very reasonable. However, I hope you realize that the required changes cannot be done in a totally backwards compatible fashion, since some names have to be swapped. The following changes seem necessary: 1. In LINKED_LIST (and descendants: LINKED_SET, LINKED_QUEUE, LINKED_STACK, SORTED_LIST, SORTED_SET, SLP_QUEUE, TWO_WAY_LIST, TWO_WAY_TREE, LINKED_TREE, L_CIRCULAR, TWL_CIRCULAR) put_right --> add_right put_left --> add_left 2. In HTABLE (and descendants: UNIVERSE, H_TABLE) put --> add change_item --> put (swapping names) 3. In DISPENSER (and descendants: PR_QUEUE, SLP_QUEUE, QUEUE, LINKED_QUEUE, STACK, LINKED_STACK) put --> add (reintroducing obsolete features in some cases) 4. In STACK (and descendant LINKED_STACK, FIXED_STACK) change_item --> put 5. In LINKABLE (and descendant BI_LINKABLE) put_right --> link_right (?) put_between --> link_between (?) 6. In BI_LINKABLE put_left --> link_left (?) Since the necessary changes seem to be quite extensive, I suggest they be made as quickly as possible, before to much new Eiffel software has made itself dependent on the current, inconsistent, naming. -- Kim Walden Enea Data, Sweden kim@enea.se