Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!uflorida!novavax!weiner
From: weiner@novavax.UUCP (Bob Weiner)
Newsgroups: comp.lang.eiffel
Subject: Re: Problem with semantics of 'put' in Eiffel library class LINKED_LIST
Message-ID: <1757@novavax.UUCP>
Date: 23 Jan 90 01:36:21 GMT
References: <1749@novavax.UUCP> <237@eiffel.UUCP>
Organization: Motorola Inc.
Lines: 73
In-reply-to: bertrand@eiffel.UUCP's message of 21 Jan 90 03:51:27 GMT

> 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