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

Re: [eiffel-nice-library] ?

Expand Messages
  • Arno Wagner
    ... My personal feeling would be that a test a.is_equal(b) is far more intuitive then a test a.same_type(b) and then a.is_equal(b) since the first should (from
    Message 1 of 7 , Nov 1, 2002
    • 0 Attachment
      On Fri, Nov 01, 2002 at 05:41:36PM +1100, Peter Horan wrote:
      > Arno Wagner wrote:
      > >
      > > On Wed, Oct 23, 2002 at 06:09:20PM +0000, Franck Arnaud wrote:
      > > > Arno:
      > > >
      > > > > There is what I fear is a serious bug in Eiffel.
      > > > > It manifests itself in the postcondition "symmetric" of
      > > > > "is_equal" actually specifying a run-time type constraint.
      > > >
      > > > It's just one instance of a catcall. All routines taking
      > > > "like current" as a parameter create a cat call when
      > > > used polymorphically.
      >
      > It is not a catcall if availability is not changed.
      >
      > Can someone remind me of the technical reasons why we cannot say
      > a.is_equal(b: ANY) ?

      My personal feeling would be that a test

      a.is_equal(b)

      is far more intuitive then a test

      a.same_type(b) and then a.is_equal(b)

      since the first should (from my feeling) have the semantics of the
      second by default. Perhaps the reason is simply that ETL defined the
      argument of 'is_equal' to be 'like Current' and nobody dared change it
      so far.

      However, contradictory as it sounds, basic comparison (for equality
      only) is not the business of COMPARABLE. This is a quation that has to
      be addressed in GENERAL. For the moment we have to live with the
      restrictions GENARAL imposes.

      However, should there not be strong reasons not to, we can
      make the the comparison operators in GENERAL the next subject
      for dicussion. Since this group probably has a good insight into
      the issue at the moment this would likely be a good thing.

      What about this discussion schedule for the next weeks:

      1. Provisionally finish the discussion on COMPARABLE with
      a vote that accepts it for now.

      2. Discuss 'is_equal', 'standard_equal', 'standard_is_equal',
      'equal' of COMPARABLE and probably make them more general
      with respect to the argument types allowed.

      3. Re-visit COMPARABLE if needed.

      4. Re-visit comparison in STRING.

      5. Proceed with the original schedule.


      Of course if Peter and me are overlooking some strong arguments
      against against widening the semantics of the comparison
      operators it would be good to find out soon....

      Arno

      --
      Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
      GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
      ----
      For every complex problem there is an answer that is clear, simple,
      and wrong. -- H L Mencken
    • Peter Horan
      Arno Wagner wrote: ... What crystalised it for me was the recognition that like Current implies dynamic arguments and therefore, the precondition of the
      Message 2 of 7 , Nov 1, 2002
      • 0 Attachment
        Arno Wagner wrote:

        I wrote:
        > > Can someone remind me of the technical reasons why we cannot say
        > > a.is_equal(b: ANY) ?
        >
        > My personal feeling would be that a test
        >
        > a.is_equal(b)
        >
        > is far more intuitive then a test
        >
        > a.same_type(b) and then a.is_equal(b)
        >
        > since the first should (from my feeling) have the semantics of the
        > second by default. Perhaps the reason is simply that ETL defined the
        > argument of 'is_equal' to be 'like Current' and nobody dared change it
        > so far.

        What crystalised it for me was the recognition that "like Current" implies
        dynamic arguments and therefore, the precondition of the signature is
        "dynamically, other is like current". So this precondition can be mapped to an
        implication of the result in the postcondition and made static.

        > However, contradictory as it sounds, basic comparison (for equality
        > only) is not the business of COMPARABLE. This is a quation that has to
        > be addressed in GENERAL. For the moment we have to live with the
        > restrictions GENARAL imposes.

        Yes. That thought flitted past without investigation because comparable is
        really about "<", not is_equal. Perhaps we should be thinking about EQUATABLE or
        EQUABLE for "is_equal".

        > However, should there not be strong reasons not to, we can
        > make the the comparison operators in GENERAL the next subject
        > for dicussion. Since this group probably has a good insight into
        > the issue at the moment this would likely be a good thing.
        >
        > What about this discussion schedule for the next weeks:
        >
        > 1. Provisionally finish the discussion on COMPARABLE with
        > a vote that accepts it for now.
        >
        > 2. Discuss 'is_equal', 'standard_equal', 'standard_is_equal',
        > 'equal' of COMPARABLE and probably make them more general
        > with respect to the argument types allowed.
        >
        > 3. Re-visit COMPARABLE if needed.
        >
        > 4. Re-visit comparison in STRING.
        >
        > 5. Proceed with the original schedule.

        This is a fine plan.
        --
        Peter Horan School of Information Technology
        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)
      Your message has been successfully submitted and would be delivered to recipients shortly.