[eiffel-nice-library] Re: STRING: infix "+"
- Thank you. I vote on support to infix "+" (or "&", whatever it's chosen).
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.
- James McKim wrote:
> > > 3. Give up on concatenation of objects of differentI agree. And I note and accept your "big if".
> > > 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.
> > > 2. Don't use `is_equal' in the postcondition of `+', and, in fact,Maybe the following approach can avoid this dilemma, by using 'out' to
> > > 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...
reduce everything to a STRING in the postcondition:
initial: Result.substring (1, count).out.is_equal (Current.out)
Result.substring (count + 1, count + other.count).out
> Maybe we need a vote to see if we should add this[TBD = "to be decided"]
> `identical_contents' feature, with the name TBD.
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 removedAbsolutely right! I misunderstood your comment to mean that ISE had very
> > > 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.
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.
Roger Browne - roger@... - Everything Eiffel
6 Bambers Walk Wesham PR4 3DG UK - +44 1772 687525