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

Re: [eiffel_software] Re: Where do you draw the line?

Expand Messages
  • Berend de Boer
    ... Hash: SHA1 ... And the performance hit would be huge. Should be an option. Why not add an is_read_only property? Wouldn t that solve the issues? - --
    Message 1 of 61 , Jan 1, 2005
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Roger Browne <roger@...> writes:

      > I have long advocated that Eiffel should have an immutable STRING type.
      > Apart from the benefits when writing Eiffel software, it would simplify
      > calls to Java and dotNet.

      And the performance hit would be huge. Should be an option. Why not
      add an is_read_only property? Wouldn't that solve the issues?

      - --
      Regards,

      Berend de Boer
      (PGP public key: http://www.pobox.com/~berend/berend-public-key.txt)
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.2.3 (GNU/Linux)
      Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

      iD8DBQFB1liIIyuuaiRyjTYRAoTrAJ9DvRzY0HMwIYGPjs1fO6GDDSeUqwCgqs7J
      Pkx6EBsLlPWJkAiPR+DvcMI=
      =UpwN
      -----END PGP SIGNATURE-----
    • Thomas Beale
      ... Hm. I don t think I have ever actually used the keyword expanded in 15 years of using Eiffel. I would be surprised to learn that there were a lot of
      Message 61 of 61 , Jan 11, 2005
        prunesquelch wrote:

        >--- In eiffel_software@yahoogroups.com, "Emmanuel Stapf [ES]"
        ><manus@e...> wrote:
        >
        >
        >
        >>This is one of the major achievement of the ECMA standardization
        >>
        >>
        >committee, there
        >
        >
        >>is only one difference between expanded and reference, it is the
        >>
        >>
        >reattachment
        >
        >
        >>semantic which is the one we know today with a minor modification.
        >>
        >>
        >Basically:
        >
        >
        >>a, b: ANY
        >>i: INTEGER
        >>
        >>`a := i' means that `a' is attached a copy of `i' and dynamic type
        >>
        >>
        >of `a' is
        >
        >
        >>INTEGER.
        >>
        >>`b := a' means that `b' is attached a copy of `a' because dynamic
        >>
        >>
        >type of `a' is
        >
        >
        >>INTEGER (expanded and thus the copy semantic)
        >>
        >>
        >
        >Am I right in thinking that this is a change which could break
        >numerous existing programmes?
        >While I appreciate efforts to make Eiffel the ideal language, surely
        >one's duty to one's users precludes such a change?
        >
        >
        Hm. I don't think I have ever actually used the keyword "expanded" in 15
        years' of using Eiffel. I would be surprised to learn that there were a
        lot of programs that broke due to this change. On the other hand I have
        written thousands of lines of code to deal with the really annoying type
        non-conformance of basic types (mixed up with atomic reference types
        like strings, dates, times, etc) to ANY. If this is now fixed - it would
        be a breakthrough achievement for Eiffel - I cannot think of any other
        single change which would improve the quality, readability, and
        maintainability of Eiffel software than being able to ignore the type
        non-conformance caused by expandedness.

        I imagine that if Bertrand (or whoever else) had originally thought of
        this generalised conversion mechanism early on in the evolution of
        Eiffel, there would not be, for all practical purposes, any need for
        thinking of expanded as having type implications - only the compiler
        writers would really care. Or am I inferring to much here?

        BTW, we have tons of code with INTEGER_REF, DOUBLE_REF and all kinds of
        ugly stuff to deal with this.
        a) When is it likely that I can throw out this code and just write it
        the way it wants to be written?
        b) will a new version of BASE contain additions to INTEGER and friends
        that will do all the appropriate conversions? Obviously how these types
        are actually handled wants to be standardised - we don't want to be
        writing our own INTEGER reference <-> expanded conversion routines...

        - thomas beale



        - thomas beale
      Your message has been successfully submitted and would be delivered to recipients shortly.