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

Intermezzo: Current status.

Expand Messages
  • Arno Wagner
    O.k., I have to admit I did not follow all of the discussion. However the most important issue seems the new semantics of like Current . Decoupling is_equal
    Message 1 of 4 , Dec 11, 2002
    • 0 Attachment
      O.k., I have to admit I did not follow all of the discussion.
      However the most important issue seems the new semantics of
      'like Current'. Decoupling 'is_equal' from 'standard_is_equal'
      makes sense to me with this change.

      This leaves the problems with the types in the postconditions.
      This is again the old ELKS version:

      is_equal (other: like Current): BOOLEAN
      -- Is `other' attached to an object considered equal
      -- to current object?
      require
      other_not_void: other /= Void
      ensure
      consistent: standard_is_equal (other) implies Result
      same_type: Result implies same_type (other)
      symmetric: Result implies other.is_equal (Current)


      Decoupling the 'standard_' features from this would mean
      removing 'consistent'. I see no problem with that.

      So removing 'same_type' would also mean that something should
      be done about 'symmetric'.
      Let me see...

      Lets suppose we drop 'same_type' and keep 'symmetric'.

      With 'other' being 'like Current' we still have the possible
      run-time type errors if 'other' has not the same type as
      current. Now assume 'other' was redefined to be, say, COMPARABLE
      in COMPARABLE. Then 'other' would conform to COMPARABLE
      and hence its 'is_equal' feature would accept anything conforming
      to COMPARABLE as an argument.

      I think this is what we want.

      So the proposal would be to just change 'is_equal' like this:

      is_equal (other: like Current): BOOLEAN
      -- Is `other' attached to an object considered equal
      -- to current object?
      require
      other_not_void: other /= Void
      ensure
      symmetric: Result implies other.is_equal (Current)

      and accept that for general usage the catcall exists, but that
      it can be redeemd when comparison for equality is modified
      to some equivalence relation on some set of types (conforming to a
      basic type like COMPARABLE or NUMERIC), where children may be compared
      to parents, because the notion of euqlity transcends the whole
      set of types. In that sense we would actually want is_equal to be
      a congruence relation, meaning that it would need to respect
      operations.

      I am not sure I have really gotten it, but together with
      the ability to redefine 'like Current' wouldn't that do what
      we want?

      Regards,
      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
    • Eric Bezault
      ... Can someone give me an example where we would want to have `is_equal to return false even when `standard_is_equal returns true? Just curious... -- Eric
      Message 2 of 4 , Dec 11, 2002
      • 0 Attachment
        Arno Wagner wrote:
        >
        > This leaves the problems with the types in the postconditions.
        > This is again the old ELKS version:
        >
        > is_equal (other: like Current): BOOLEAN
        > -- Is `other' attached to an object considered equal
        > -- to current object?
        > require
        > other_not_void: other /= Void
        > ensure
        > consistent: standard_is_equal (other) implies Result
        > same_type: Result implies same_type (other)
        > symmetric: Result implies other.is_equal (Current)
        >
        > Decoupling the 'standard_' features from this would mean
        > removing 'consistent'.

        Can someone give me an example where we would want to have
        `is_equal' to return false even when `standard_is_equal'
        returns true? Just curious...

        --
        Eric Bezault
        mailto:ericb@...
        http://www.gobosoft.com

        _____________________________________________________________________
        Envie de discuter en "live" avec vos amis ? T�l�charger MSN Messenger
        http://www.ifrance.com/_reloc/m la 1�re messagerie instantan�e de France
      • Alexander Kogtenkov
        ... The possible definition might be is_equal (other: ...) is do Result := Current = other end but the class with such a feature cannot implement the feature
        Message 3 of 4 , Dec 15, 2002
        • 0 Attachment
          Eric Bezault wrote:

          > Can someone give me an example where we would want to have
          > `is_equal' to return false even when `standard_is_equal'
          > returns true? Just curious...

          The possible definition might be

          is_equal (other: ...) is
          do
          Result := Current = other
          end

          but the class with such a feature cannot implement the feature "copy".

          Regards,
          Alexander Kogtenkov
          Object Tools, Moscow
        • Eric Bezault
          ... Indeed, so it is not a good example for having `is_equal to return false even when `standard_is_equal returns true. But this brings back to my mind
          Message 4 of 4 , Dec 15, 2002
          • 0 Attachment
            Alexander Kogtenkov wrote:
            >
            > Eric Bezault wrote:
            >
            > > Can someone give me an example where we would want to have
            > > `is_equal' to return false even when `standard_is_equal'
            > > returns true? Just curious...
            >
            > The possible definition might be
            >
            > is_equal (other: ...) is
            > do
            > Result := Current = other
            > end
            >
            > but the class with such a feature cannot implement the feature "copy".

            Indeed, so it is not a good example for having `is_equal' to return
            false even when `standard_is_equal' returns true. But this brings
            back to my mind something that I already mentioned in the past and
            that does not seem to be take into account in the recent discussions
            about `is_equal': we should not forget that one raison d'etre of
            `is_equal' in ANY is to be used as postcondition of `copy'. Therefore
            their semantics are linked to each other, and specifying a new set of
            assertions for `is_equal' should not be done without considering it
            effect on the definition of `copy'.

            --
            Eric Bezault
            mailto:ericb@...
            http://www.gobosoft.com


            _____________________________________________________________________
            GRAND JEU SMS : Pour gagner un NOKIA 7650, envoyez le mot IF au 61321
            (prix d'un SMS + 0.35 euro). Un SMS vous dira si vous avez gagn�.
            R�glement : http://www.ifrance.com/_reloc/sign.sms
          Your message has been successfully submitted and would be delivered to recipients shortly.