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

ARRAY:subarray spec

Expand Messages
  • Peter Horan
    I was looking at this last night and wondered why I had written code which assumed subarray (min, max: INTEGER): like Current rather than subarray (min, max:
    Message 1 of 6 , Mar 13, 2002
    • 0 Attachment
      I was looking at this last night and wondered why I had written code
      which assumed
      subarray (min, max: INTEGER): like Current
      rather than
      subarray (min, max: INTEGER): ARRAY [G]

      Apart from the name, why should the result not be anchored to Current?
      --
      Peter Horan School of Computing and Mathematics
      peter@... Deakin University
      +61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
      +61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter

      -- The Eiffel guarantee: From specification to implementation
      -- (http://www.cetus-links.org/oo_eiffel.html)
    • Arno Wagner
      ... Because subARRAY is supposed to be an ARRAY. Current might not be an ARRAY anymore. Also the parameters min, max might not be enough to determine a
      Message 2 of 6 , Mar 14, 2002
      • 0 Attachment
        On Thu, Mar 14, 2002 at 11:34:42AM +1100, Peter Horan wrote:
        > I was looking at this last night and wondered why I had written code
        > which assumed
        > subarray (min, max: INTEGER): like Current
        > rather than
        > subarray (min, max: INTEGER): ARRAY [G]
        >
        > Apart from the name, why should the result not be anchored to Current?

        Because subARRAY is supposed to be an ARRAY. Current might not be an
        ARRAY anymore. Also the parameters min, max might not be enough to
        determine a subpart of Current but will allways be enough to determine
        a subarray of Current viewed as/abstracted to an ARRAY.

        Of course a part of current that when viewed as an array is the
        subarray in question would do the job in most cases. But with the
        name subARRAY, that specifies the result type, a developer should not
        need to make arbitrary decision about the behaviour of additional
        non-ARRAY properties under this operation. In fact the additional
        properties might become worthless as they are not specified with ARRAY
        and properties that behave arbitrarily are better not to have at all.

        My view would be that a function with a type name A in its name should
        always return an object of type A. If it is further implied that the
        object type the function is called on (lets call it B) has a specific
        type, the the function should behave excatly as if it was called on
        Current abstracted to type B, i.e.

        C.<operation_on_B>_<with_resulttype_A>

        should fists abstract/convert C to B and then return an A
        as if it was called on the B. (I am mixing types and objects here,
        but I think it gets the point across.) One huge benefit is that
        these operations do not need to be reimplemented in a child class!


        On a related issue, I don't remember whether I argued against
        "substring" in STRING returning a Current (which I think is wrong).
        This is just a thing that might have been too longstanding to change.

        My view would be that "substring" must return a STRING (no harm in the
        present situation, except that implementors of subclasses have to make
        arbitrary decision, reimplement the feature and possible
        inefficiencies may arise) and that an operation that returns a Current
        should be called subcurrent or here subsequence or sub<Type of
        Current> (e.g. subcoloredstring).

        With ARRAY it is somewhat easier, as an ARRAY is usually not
        supposed to have additional properties that are not tied
        to individual elements and elements are free with regard to
        their type (given a general enough type parameter).

        Overall my position is that if a function implies a result and/or
        argument type it must operate and return these types, abstracting a
        more general argument if needed before executing the operation.

        Arno
        --
        Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
        GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

        A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
        affect the vessel's performance. -- New Scientist on the paperless office
      • Greg C
        ... Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What if you ve subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the second
        Message 3 of 6 , Mar 14, 2002
        • 0 Attachment
          >
          > I was looking at this last night and wondered why I had written code
          > which assumed
          > subarray (min, max: INTEGER): like Current
          > rather than
          > subarray (min, max: INTEGER): ARRAY [G]
          >
          > Apart from the name, why should the result not be anchored to Current?

          Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
          if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
          second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
          the function should be anchored to Current, right?

          Greg

          =====
          http://www.geocities.com/gmc444/gregs.html
          Apologies for the stupid Yahoo ad below.

          __________________________________________________
          Do You Yahoo!?
          Yahoo! Sports - live college hoops coverage
          http://sports.yahoo.com/
        • Arno Wagner
          ... Ha, ha! (Another fool here!) But what if (min,max) is not enough to specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the concept of a
          Message 4 of 6 , Mar 14, 2002
          • 0 Attachment
            On Thu, Mar 14, 2002 at 09:52:28AM -0800, Greg C wrote:
            > >
            > > I was looking at this last night and wondered why I had written code
            > > which assumed
            > > subarray (min, max: INTEGER): like Current
            > > rather than
            > > subarray (min, max: INTEGER): ARRAY [G]
            > >
            > > Apart from the name, why should the result not be anchored to Current?
            >
            > Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
            > if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
            > second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
            > the function should be anchored to Current, right?

            Ha, ha! (Another fool here!) But what if (min,max) is not enough to
            specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
            concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
            because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
            everybody can see by breaking a fishing pole into parts...) If you
            ignore the FISHING_POLE the subarraying still works!

            Arno
            --
            Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
            GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

            A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
            affect the vessel's performance. -- New Scientist on the paperless office
          • Roger Browne
            Hi, I m back now, and will aim to address all outstanding issues raised in this group (eventually). After that, I ll need to hand over to someone else because
            Message 5 of 6 , Mar 21, 2002
            • 0 Attachment
              Hi, I'm back now, and will aim to address all outstanding issues raised
              in this group (eventually).

              After that, I'll need to hand over to someone else because I'm about to
              start on a new project that will be very demanding.

              On 14 March, Peter Horan wrote:

              > I ... wondered why I had written code which assumed
              > subarray (min, max: INTEGER): like Current
              > rather than
              > subarray (min, max: INTEGER): ARRAY [G]
              >
              > Apart from the name, why should the result not be anchored to Current?

              The confusion is my fault, because I have not managed to keep all the web
              pages up-to-date.

              Last year, we carefully went through the result types of all functions in
              STRING and ARRAY, and changed several of them to "like Current",
              including the result type of 'subarray'.

              The details of this proposal, and the vote, are here:

              http://www.eiffel-nice.org/standards/wip/array/elks2002changes.html

              However, not all of those changes have yet been applied to the "Draft
              ELKS 2002 ARRAY" page, which is here:

              http://www.eiffel-nice.org/standards/wip/array/array2002proposal.txt

              I'll apply all the outstanding changes in the next few days, and post a
              message to this group when this page is up-to-date.

              Following Peter's comment of March 14, some discussion ensued. Arno
              posted a carefully-argued case for having a signature of "ARRAY[G]", but
              I won't quote it in this message because it's summarised by the following
              exchange between Greg and Arno.

              Greg C wrote:

              > Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
              > if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
              > second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
              > the function should be anchored to Current, right?

              Arno Wagner replied:

              > Ha, ha! (Another fool here!) But what if (min,max) is not enough to
              > specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
              > concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
              > because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
              > everybody can see by breaking a fishing pole into parts...) If you
              > ignore the FISHING_POLE the subarraying still works!

              When we discussed this (prior to the September 2001 vote), both of these
              situations were considered.

              A subclass of ARRAY or STRING might add a new attribute. There are two
              possibilities:

              (P1) The new attribute is a single object or value that relates to the
              entire ARRAY or STRING sequence

              (P2) The new attribute is itself a data structure with multiple
              components each of which relates to some part of the ARRAY or STRING
              sequence

              Suppose we have a descendant of STRING. If that descendant adds a
              'copyright' attribute to indicate to whom the copyright of that string
              belongs, then we have an example of (P1). If, on the other hand, the
              descendant adds an ARRAY[FONT] to indicate the FONT to be used for each
              CHARACTER, then we have an example of (P2).

              In last year's discussions it was decided that case (P1) is likely to be
              much more common than case (P2), and that we should design ARRAY and
              STRING so that the minimum of redefinition is required in case (P1).
              Furthermore, we felt that a general solution was available for (P1), but
              not for (P2).

              In addition to the changes that we made to support (P1), we also added
              the functions 'string' and 'array' to classes STRING and ARRAY
              respectively. When inherited into a proper descendant of STRING or ARRAY,
              these functions return the ARRAY or STRING sequence as an object of type
              STRING or ARRAY (and therefore without any attributes added by the
              descendant).

              So, to recap. Peter Horan was assuming this signature:

              subarray (min, max: INTEGER): like Current

              and this is what is intended for ELKS 2002 ARRAY. Arno preferred this
              signature:

              subarray (min, max: INTEGER): ARRAY [G]

              and can achieve the same effect in ELKS 2002 ARRAY by calling
              "foo.array.subarray(min, max)" instead of "foo.subarray(min, max)".

              This might all seem rather arbitrary ("Nero fiddling while Rome burns,
              etc"). But the driving force behind the September 2001 changes was not to
              fiddle with the signatures. It was to make descendants of STRING and
              ARRAY usable. The mixture of signatures in ELKS95 was unworkable in
              descendants, as many postconditions failed in the descendant classes. We
              _had_ to make the signatures consistent, and as part of that process we
              had to decide whether to choose a solution that facilitated (P1) or (P2)
              above. We chose the solution that facilitated (P1).

              This stuff is buried in the archives, and it is not easy to reconstuct
              the historical train-of-thought. Ideally, someone will write an
              "Annotated ELKS" document that explains all the design decisions. But
              that will be a big job.

              Regards,
              Roger
              --
              Roger Browne - roger@... - Everything Eiffel
              19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
            • Arno Wagner
              ... [...] ... [...] ... Actually I did not remember we discussed it already. If P1 is really more, likely a result of Current is indeed more useful. Let s
              Message 6 of 6 , Mar 22, 2002
              • 0 Attachment
                On Thu, Mar 21, 2002 at 09:26:40PM +0000, Roger Browne wrote:
                > Hi, I'm back now, and will aim to address all outstanding issues raised
                > in this group (eventually).
                [...]
                > Greg C wrote:
                >
                > > Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
                > > if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
                > > second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
                > > the function should be anchored to Current, right?
                >
                > Arno Wagner replied:
                >
                > > Ha, ha! (Another fool here!) But what if (min,max) is not enough to
                > > specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
                > > concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
                > > because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
                > > everybody can see by breaking a fishing pole into parts...) If you
                > > ignore the FISHING_POLE the subarraying still works!
                >
                > When we discussed this (prior to the September 2001 vote), both of these
                > situations were considered.
                >
                > A subclass of ARRAY or STRING might add a new attribute. There are two
                > possibilities:
                >
                > (P1) The new attribute is a single object or value that relates to the
                > entire ARRAY or STRING sequence
                >
                > (P2) The new attribute is itself a data structure with multiple
                > components each of which relates to some part of the ARRAY or STRING
                > sequence
                [...]
                > This might all seem rather arbitrary ("Nero fiddling while Rome burns,
                > etc"). But the driving force behind the September 2001 changes was not to
                > fiddle with the signatures. It was to make descendants of STRING and
                > ARRAY usable. The mixture of signatures in ELKS95 was unworkable in
                > descendants, as many postconditions failed in the descendant classes. We
                > _had_ to make the signatures consistent, and as part of that process we
                > had to decide whether to choose a solution that facilitated (P1) or (P2)
                > above. We chose the solution that facilitated (P1).
                >
                > This stuff is buried in the archives, and it is not easy to reconstuct
                > the historical train-of-thought. Ideally, someone will write an
                > "Annotated ELKS" document that explains all the design decisions. But
                > that will be a big job.

                Actually I did not remember we discussed it already.
                If P1 is really more, likely a result of Current is
                indeed more useful.

                Let's revisit this for ELKS2010 though!

                Regards,
                Arno

                --
                Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
                GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

                A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
                affect the vessel's performance. -- New Scientist on the paperless office
              Your message has been successfully submitted and would be delivered to recipients shortly.