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)
Result.substring (count + 1, count + other.count).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.
Roger Browne - roger@...
- Everything Eiffel
6 Bambers Walk Wesham PR4 3DG UK - +44 1772 687525