Loading ...
Sorry, an error occurred while loading the content.
 

[eiffel-nice-library] STRING: infix "+"

Expand Messages
  • Roger Browne
    The egroups poll for infix + has now closed. Thanks to those who voted. It s clear that there s strong support to add a string concatenation function to
    Message 1 of 72 , Oct 31, 1999
      The egroups poll for infix "+" has now closed. Thanks to those who
      voted. It's clear that there's strong support to add a string
      concatenation function to class STRING - but late votes are still
      accepted and welcome, and will be added to the results page.

      There was one vote strongly opposing this proposal. Every such vote is a
      reminder that some users are going to be unhappy with some aspect of
      ELKS 2000. We should work hard to structure the changes so that they
      attract the least possible opposition. So far we've done pretty well -
      but some more controversial issues lie ahead.


      During the discussion, many different variations of the string
      concatenation function were proposed. I said that we could vote on these
      as amendments to refine the following version:

      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)

      You can propose amendments now, or else you can wait to see how the rest
      of ELKS 2000 shapes up before you propose an amendment (there will be a
      call for proposed amendments before the ELKS 2000 submission is frozen).

      I will call a vote on any amendment that is requested by three or more
      people.

      Regards,
      Roger
      --
      Roger Browne - roger@... - Everything Eiffel
      6 Bambers Walk Wesham PR4 3DG UK - +44 1772 687525
    • Roger Browne
      ... I agree. And I note and accept your big if . ... Maybe the following approach can avoid this dilemma, by using out to reduce everything to a STRING in
      Message 72 of 72 , Nov 7, 1999
        James McKim wrote:

        > > > 3. Give up on concatenation of objects of different
        > > > types....
        > >
        > > Or, adopt (3), but only as an interim measure. (This is not a big
        > > limitation - after all any object can have ".out" applied to it to yield
        > > a STRING.)
        >
        > _If_ we do this I would like to see the `same_type' precondition put in.

        I agree. And I note and accept your "big if".

        > > > 2. Don't use `is_equal' in the postcondition of `+', and, in fact,
        > > > probably don't use it in _any_ postconditions.

        > It looks to me like the cleanest safest solution for now is (2).
        > For a checkable spec we'd need something ('identical_contents' or
        > whatever) to replace `is_equal' in the postconditions. I _hate_
        > the idea of adding a feature to the spec this year, only to discover
        > that, because of a modification to `is_equal' or some such change, we
        > don't need it next year...

        Maybe the following approach can avoid this dilemma, by using 'out' to
        reduce everything to a STRING in the postcondition:

        initial: Result.substring (1, count).out.is_equal (Current.out)
        final:
        Result.substring (count + 1, count + other.count).out
        .is_equal (other.out)

        > Maybe we need a vote to see if we should add this
        > `identical_contents' feature, with the name TBD.
        [TBD = "to be decided"]

        I'm happy to see a discussion and a vote on this. But I'd like to see a
        proposal that addresses the issue in both STRING and ARRAY.

        > > > BTW, ISE has removed
        > > > that postcondition clause from its version of `is_equal'.
        > >
        > > ISE agreed to this in 1995...
        >
        > Well, all of the vendors have known about ELKS 95 for a long time
        > and none are in full compliance, so I think it's unfair to single
        > out any one of them.

        Absolutely right! I misunderstood your comment to mean that ISE had very
        recently removed this postcondition, i.e. had "gone backwards" with ELKS
        95 support. Sorry!

        Ultimately, the degree of vendor support for an interoperable kernel
        will depend upon how loudly users insist on it.

        Regards,
        Roger
        --
        Roger Browne - roger@... - Everything Eiffel
        6 Bambers Walk Wesham PR4 3DG UK - +44 1772 687525
      Your message has been successfully submitted and would be delivered to recipients shortly.