work in progress | array


proposals for class ARRAY

1. Refine the specification of is_equal
2. Correct an error in the specification of feature is_equal

Proposal

Refine the specification of 'is_equal' to:
   is_equal (other: like Current): BOOLEAN
         -- Do both arrays have the same `lower', `upper', and items?
         -- (Redefined from GENERAL.)
      require -- from GENERAL
         other_not_void: other /= Void
      ensure -- from GENERAL
         consistent: standard_is_equal (other) implies Result
         same_type: Result implies same_type (other)
         symmetric: Result implies other.is_equal (Current)
      ensure then
         definition: Result =
          ((lower = other.lower) and then
          (upper = other.upper) and then
             (count = 0 or else
             (item (upper) = other.item (upper) and
             subarray (lower, upper - 1).is_equal
             (other.subarray (lower, upper - 1)))))

Notes

This proposal has two main effects: All vendors accept the first of these points. The second one is problematic, because the SmallEiffel team are very keen to have the 'is_equal' behaviour. Here's how I intend to handle this issue:

History

The 1995 standard is not precise.

VE and SE appear to check lower and upper, ISE and HACT appear not to.
ISE, HACT and VE use "=" to compare the ARRAY elements, SE uses 'is_equal'.

Rationale

lower and upper are fundamental to the ARRAY abstraction and should therefore be considered by is_equal.

Discussion Excerpts

Dominique Colnet, 30 August 1999:

Is equal should definitely compare elements AND bounds. Doing otherwise
would be a departure from its definitition in the Eiffel language.

Jim McKim, 30 August 1999:

Sigh. _You_ may think this is obvious, and _I_ may think this is obvious,
and the TOOLS USA group may think it is obvious, but if we don't write
it down, it is not going to be obvious to everyone. In fact the inventor
of Eiffel disagrees. Or to be more precise, ISE Eiffel v4.2 just
compares the elements, not the bounds. I suspect the argument for doing it
this way is precisely to make it easy to do the things I mentioned in
the post you're citing: compare subarrays to each other, and to manifest
arrays...

Jim McKim, 21 October 1999:

The latest ETL (unless it's changed in the last few weeks) shows the
same short form as in this one, except that the bounds are compared as
well.

Impact of proposed change

Result

The proposal was accepted.

votes cast at eGroups:

Strongly accept the proposal
                richieb@netlabs.net
                genepi@sympatico.ca
Accept the proposal
                sergei_ivanov@object-tools.com
                jcm@mstr.hgc.edu
                peter@deakin.edu.au
                manus@eiffel.com
                joachim.durchholz@halstenbach.de
                kevin@ethossoft.co.nz
                sparker@eiffel.ie
                ericb@gobosoft.com
                tking@insystems.com
                xavier@halstenbach.com
                kwaxer@aha.ru
                jweirich@one.net
                franck.arnaud@omgroup.com

votes sent by email:

abstain:
                "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de>

Amendment

Proposal for class ARRAY:

Correct an error in the specification of feature 'is_equal':

This poll is to correct an error in the postcondition
of 'is_equal', by replacing the existing 'definition'
assertion with one of the following two alternatives:

FIX "A" (using 'same_items'):

definition: Result =
   (same_type (other) and then (lower = other.lower) 
                           and then same_items (other))
FIX "B" (not using 'same_items'):
definition: Result =
   (same_type (other) and then
      -- Both array objects are the same type and ...
   (lower = other.lower) and then (upper = other.upper) and then
      -- Corresponding bounds are the same and ...
   (count = 0 or else
      -- Both arrays are empty or ...
   (item (upper) = other.item (upper) and
      -- Both "upper" items are the same and ...
   subarray(lower, upper - 1).is_equal
    (other.subarray(lower, upper - 1)))))
      -- All the rest of the corresponding items are the same.

Result

FIX "A" was preferred.

votes cast at eGroups:

Strongly prefer FIX "A"
                jweiric-@one.net
                saunder-@wchat.on.ca
Prefer FIX "A"
                franck.arnau-@omgroup.com
                eric-@gobosoft.com
                pete-@deakin.edu.au
                manu-@eiffel.com
                jc-@rh.edu
Don't mind (happy either way)
                kwaxe-@aha.ru
Prefer FIX "B"
                sergei_ivano-@object-tools.com
                wagne-@ti.uni-trier.de

votes sent by email:

Prefer FIX "A": 
                "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>