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

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

Expand Messages
  • Jose Monserrat Neto
    Thank you. I vote on support to infix + (or & , whatever it s chosen). Monserrat.
    Message 1 of 72 , Nov 1, 1999
    • 0 Attachment
      Thank you. I vote on support to infix "+" (or "&", whatever it's chosen).

      Monserrat.

      Roger Browne wrote:

      > 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.
    • 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
      • 0 Attachment
        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.