weiner@novavax.UUCP (Bob Weiner) (01/20/90)
This note refers to V2.2B of ISE's Eiffel libraries. I have a problem with the semantics of the LINKED_LIST 'put' operation. I believe they should be different. Specifically, a list put should be an insertion rather than a replacement operation as it presently is. (Presently 'put_left' and 'put_right' must be used for insertion.) I propose that 'put' should be the same as 'put_left' and the operation that 'put' now performs should be renamed 'replace' for clarity. Any housewife or professional programmer knows that putting something into a list does not eliminate any of the other list items, hence the need for the change. Additionally, the current semantics conflicts with the 'put' of SORTED_LIST which is an insert operation. ARRAY put operations do replace the item indexed in the array but this is what one would naturally expect and bears no relation to the best semantics for a LIST put. I am very surprised that no one else has mentioned this but I think it is important since programmers can too easily overrite LIST elements. -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 364-2087
bertrand@eiffel.UUCP (Bertrand Meyer) (01/21/90)
In <1749@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) suggests changing the semantics of ``put'' in the list classes of the Data Structure library. The effect would be the same as that of ``put_left''. The referenced message only talks about LINKED_LIST but of course the same change would have to be made to other list classes as well. I am somewhat puzzled by the suggestion: - Why choose the semantics of put_left rather than that of put_right? - Since we already have put_left, why have another procedure which has a different name and the same effect? Although synonyms may make sense in some cases, basic libraries should be both complete and minimal (``the relevant features, all the relevant features, nothing but the relevant features''). The feature name set should be minimal too. - An operation such as the one currently called ``put'' will be needed anyway. After changing the semantics of the current ``put'', we would reintroduce a routine with the old semantics and another name! I have argued in this newsgroup and elsewhere that one should not be afraid of change if it is carried out professionally and responsibly. But this applies to change that is needed. In this particular case, I can't see anything wrong with the current status of put, put_left and put_right. -- Bertrand Meyer bertrand@eiffel.com
uucibg@swbatl.UUCP (3929) (01/22/90)
In article <237@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >In <1749@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) suggests changing >the semantics of ``put'' in the list classes of the Data Structure >library. The effect would be the same as that of ``put_left''. >The referenced message only talks about LINKED_LIST but of >course the same change would have to be made to other list >classes as well. > >I am somewhat puzzled by the suggestion: > >- Why choose the semantics of put_left rather than that of put_right? Good point. >- Since we already have put_left, why have another procedure which has >a different name and the same effect? Although synonyms may make sense >in some cases, basic libraries should be both complete and minimal >(``the relevant features, all the relevant features, nothing but the >relevant features''). The feature name set should be minimal too. Also a good point. >- An operation such as the one currently called ``put'' will be needed >anyway. After changing the semantics of the current ``put'', we would >reintroduce a routine with the old semantics and another name! True. >I have argued in this newsgroup and elsewhere that one should not >be afraid of change if it is carried out professionally and responsibly. >But this applies to change that is needed. In this particular case, >I can't see anything wrong with the current status of put, put_left >and put_right. For me (someone who has never used Eiffel; I hope to change that in the near future), the problem lies in "semantic distance" versus "functional distance". In this case, we have three routines which have the same semantic root (the verb "put"), but one of them behaves in a fundamentally different manner. I would argue for changing the name of "put" to "replace" and leaving it at that. This preserves the "features, needed features, and nothing but the needed features" issue. It also places some semantic "distance" between the routines which will hopefully help the class automatically document itself (well, we all know that is tough, but this would help). For me, it certainly helps to re-inforce the fact that the routines behave differently. Of course, there's probably some good reason why this won't work... :-) >-- Bertrand Meyer >bertrand@eiffel.com Just thought the viewpoint of a neophyte might be interesting... Brian Gilstrap ( uucibg@swbatl.UUCP )
weiner@novavax.UUCP (Bob Weiner) (01/23/90)
> In <1749@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) suggests changing > the semantics of ``put'' in the list classes of the Data Structure > library. The effect would be the same as that of ``put_left''. > The referenced message only talks about LINKED_LIST but of > course the same change would have to be made to other list > classes as well. > > I am somewhat puzzled by the suggestion: > > - Why choose the semantics of put_left rather than that of put_right? Because your 'put_left' and 'put_right' features do not move the cursor. Linked lists are often used in programs to implement stacks and queues in which addition and removal of elements occurs at the head or the tail of the list. By having 'put' implement 'put_left' one can easily use it to implement repeated insertions in both stacks and queues without the need for intervening 'forth' or 'back' feature calls. The semantics of 'put_right' support this sort of common operation. > > - Since we already have put_left, why have another procedure which has > a different name and the same effect? Although synonyms may make sense > in some cases, basic libraries should be both complete and minimal > (``the relevant features, all the relevant features, nothing but the > relevant features''). The feature name set should be minimal too. This was answered in the original message. If I wanted to name an insertion feature 'remove', certainly you would object since programmers relie on the meanings of words used in entity/feature names to understand their usage. Since putting something in a list is understood by virtually everyone to be an insertion operation rather than a replacement operation, the semantics associated with the current LIST 'put' feature are entirely too easily misconstrued. (If anyone agrees with this, you should let bertrand@eiffel.com know.) > > - An operation such as the one currently called ``put'' will be needed > anyway. After changing the semantics of the current ``put'', we would > reintroduce a routine with the old semantics and another name! The use of the 'replace' feature name to take the old semantics of 'put' (when it takes the semantics of 'put_left') would also clarify its intended operation. In this case, two feature names, 'put' and 'put_left' would do the same thing. Here practicality must take precedence over elegance in that 'put_left' must remain so as not to disturb working applications unduly. No one is trying to remove synonyms from natural languages so why should we need in every case to keep them out of class definitions? > > I have argued in this newsgroup and elsewhere that one should not > be afraid of change if it is carried out professionally and responsibly. > But this applies to change that is needed. In this particular case, > I can't see anything wrong with the current status of put, put_left > and put_right. This has already produced errors in code written by knowledgable programmers so I have difficulty understanding why the issue seems trivial to you. I think the best way to resolve this is to simply ask a number of users which they think is the better solution and to go with that. I must say, though, that if ISE were to produce documentation associated with EACH library class that explained its protocol set clearly, such naming/semantic conflicts would be much less likely. (The LIST classes are a good example of where this has not been done. And few people are used to list implementations with cursors in them!) -- Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner (407) 364-2087