work in progress | string

proposal for class STRING

Add feature infix "+"

Proposal

Proposal for class STRING:

Add feature infix "+" as a concatenation function.

        infix "+" (other: STRING): like Current
                        -- Create a new object which is the concatenation of Current and other.
                require
                        other_exists: other /= Void
                ensure
                        result_not_void: Result /= Void
                        result_count: Result.count = count + other.count
                        initial: Result.substring (1, count).is_equal (Current)
                        final: Result.substring (count + 1, count + other.count).is_equal (other)

Please select one of the following:

Strongly accept the proposal
Accept the proposal
Reject the proposal
Strongly reject the proposal
Don't mind (happy either way)
Abstain (not happy either way)

History

Feature infix "+" is not present in class STRING in the 1995 standard. It is curently implemented by HACT, VE and SE, but not yet by ISE (although they have announced their intention to support it).

Background

infix "+" is a convenience feature. It's always possible to replace this code...

   a, b: STRING
   ...
   foo(a + b)

...by this code...

   a, b, temp: STRING
   ...
   temp := clone(a)
   temp.append_string(b)
   foo(temp)

Rationale

This feature is frequently requested, and is useful when it is desired to build a STRING from a number of smaller STRINGs within a single expression.

Discussion

(The full discussion is at http://www.egroups.com/group/eiffel-nice-library)

Alexander Kogtenkov (25 October 1999):

I'm not sure, but maybe, the better signature for infix "+" is

infix "+" (other: like Current): like Current

Jim McKim (25 October 1999):

[allowing other to be void] ... "abc" + Void would be legit but Void + "abc" would not. This would certainly be confusing for new users and would probably catch veterans out from time to time as well.

Roger Browne (25 October 1999):

Perhaps there be a postcondition like the following:

new_string: result /= current and result /= other

Frieder Monninger (25 October 1999):

"abc" + Void is sometimes rather nice ... I found it rather usefull in same situation ... In fact I don't see + for STRING as symetric: "A" + "B" is not equal "B" + "A" !

so void + "X" must not necessarily work - but as I said before "X" + void makes sense.

Eric Bezault (25 October 1999):

For me concatenating void to a string doesn't make any more sense
than comparing a string with void: "foo" < Void !

Jim McKim (25 October 1999):

I agree that concatenation is not commutative. If x and y are strings I don't expect that x+y is equal to y+x. I do, however, expect that if x+y _exists_ then so does y+x.

Chris Saunders (25 October 1999):

... I personally am against the idea as this operator cannot live up to its usual specification in the context of the STRING class (not commutative, no inverse). As Eiffelist's I think that we are supposed to accept a little extra typing in the interest of clarity ... I also feel that the standard should be a minimal one - in other words, if
there is not a compelling reason for the inclusion of a feature then it should not be included ...

Joachim Durchholz (25 October 1999):

Concatenation is *the* common operation for strings, so having an operator for it is justified alone on the grounds of commonality ... Besides, string concatenation is associative, and that's still an important
property ...

Jim McKim (25 October 1999):

Note that if we allow Void as an operand we lose associativity as well.

Joachim Durchholz (25 October 1999):

In my eyes, no-change postconditions are in the same category as "definition" postconditions

Jim McKim (25 October 1999):

The closest I can come to specifying rigorously that a _new_ object is returned to the user is something like:

brand_spanking_new: Result /= old (Current + other)

This more or less guarantees that two successive calls will not return the same object. Unfortunately, in theory it puts us in the realm of infinite recursion. In practice, an Eiffel implementation will stop,
but I hate for the spec to depend on that. And a sufficiently creative implementer could still find a way for the new object to share some crucial part of `Current' in any case.

IMHO this is one place where a comment does a better job than we can do rigorously. You understand, it _hurts_ for me to say that.

Todd King (25 October 1999):

I hate that the times I've spoken up have been about excluding a particular item from the standard, but I must do it once again. Roger's hypothetical examples point out the fact that "+" doesn't have a clear and un-arguable semantic.

Emmanuel Stapf (25 October 1999):

at this point ISE is in favor of `infix "+"' which creates a new string each time it is called and that does not accept Void arguments.

Pierre Metras (25 October 1999):

What about using infix "&" instead of infix "+"

Frieder Monninger (26 October 1999):

Who would be harmed if "A" + void would be a legal expression ?

Franck Arnaud (26 October 1999):

It is not very much in the usual Eiffel style. With DBC clients are responsible about supplying meaningful entry, not supplier in checking every possible entry and falling back on their feet silently ... generally overloading Void with (untyped) meaning should not be abused.

Frieder Monninger (26 October 1999):

void has a well defined meaning ... and using it does not mean misuse ... Btw, in SQL one can concatenate one string with null ...

Jim McKim (26 October 1999):

If its really important to have a concatenation feature that handles Void strings, let's follow the lead of the `is_equal' vs `equal' debate.

concat( x, y : STRING ) : STRING
-- Creates a new object that is the concatenation of x and y.

Roger Browne (26 October 1999):

Here's another angle: it would be possible to put infix "&" into class GENERAL, something like this:

infix "&" (other: ANY): STRING is
-- New string built by concatenating 'out' and 'other.out'.
...

Then, it would be possible to write:

print(5 & " is between " & 3 & " and " & 6)

Simon Parker (26 October 1999):

I also strongly prefer '&' as the string concatenation operator.

Doug Pardee (27 October 1999):

[infix "&" in GENERAL] ... after I recovered my senses, I found the idea to be both very usable and quite elegant. I'd like to see this seriously considered (unless there's a reason it won't work).

Impact of proposed change

Low.

Result

The proposal was accepted.

Voting details

votes cast at eGroups:

Strongly reject the proposal
                tking@insystems.com
Accept the proposal
                sergei_ivanov@object-tools.com
                sparker@eiffel.ie
                richieb@netlabs.net
                franck.arnaud@omgroup.com
                objetos@satlink.com
                simonwillcocks@enterprise.net
                ericb@gobosoft.com
                saunders@wchat.on.ca
                kwaxer@aha.ru
Strongly accept the proposal
                jcm@mstr.hgc.edu
                dougpardee@my-deja.com
                genepi@sympatico.ca
                jweirich@one.net
                steinman@sco.edu

votes sent to the discussion list:

Accept the proposal
Jose Monserrat Neto <rijik@ufla.br>

emailed votes:

Accept the proposal
manus@eiffel.com