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

[eiffel-nice-library] Re: Ancestor for ARRAY and STRING

Expand Messages
  • Alexander Kogtenkov
    Ulrich Windl wrote: ... It does affect the efficiency, though in most applications the compilers can optimize the things (at least in the boost/finalize
    Message 1 of 8 , Mar 28, 2000
    • 0 Attachment
      Ulrich Windl wrote:
      ...
      > > use contiguous memory area to keep the data (Eiffel/S 1.3). So, probably it's
      > > better to start from the first class, which is a common ancestor for ARRAY and STRING.
      ...
      > I wonder: Can these rather basic classes be implemented efficiently
      > if they are descendants from a huge pile of abstract classes (like
      > EiffelBASE's SEQUENCE)?

      It does affect the efficiency, though in most applications the compilers can
      optimize the things (at least in the "boost/finalize" modes).

      > I also mean: You write "io.put_string("Hello world")" and you get the
      > whole EiffelBASE compiled and linked into your program ;-)

      Even now this code would require not just 2 classes. The question is whether we
      need highly optimized classes or highly reusable ones.

      Regards,
      Alexander Kogtenkov
      Object Tools, Moscow
    • Durchholz, Joachim
      ... This may happen for debug builds, but there are good reasons to have most of the library in such a system anyway (e.g. to facilitate recompilation). I
      Message 2 of 8 , Mar 29, 2000
      • 0 Attachment
        > From: Ulrich Windl [mailto:Ulrich.Windl@...-regensburg.de]
        >
        > I wonder: Can these rather basic classes be implemented efficiently
        > if they are descendants from a huge pile of abstract classes (like
        > EiffelBASE's SEQUENCE)?
        >
        > I also mean: You write "io.put_string("Hello world")" and you get the
        > whole EiffelBASE compiled and linked into your program ;-)
        >
        > (This was a bit true for TowerEiffel)

        This may happen for debug builds, but there are good reasons to have most of
        the library in such a system anyway (e.g. to facilitate recompilation). I
        think a production build ("finalize" or "boost") will not include any
        routines that are never called; I know that this is the case for ISE Eiffel,
        iss-base, and SmallEiffel.

        Regards,
        Joachim
        --
        This is not an official statement from my employer or from NICE.
      • Durchholz, Joachim
        ... Following the old first make it run, then make it fast saying, I d prefer the reusable ones. Efficiency should be a concern, but not the primary one;
        Message 3 of 8 , Mar 29, 2000
        • 0 Attachment
          > From: Alexander Kogtenkov [mailto:kwaxer@...]
          >
          > The question is whether we
          > need highly optimized classes or highly reusable ones.

          Following the old "first make it run, then make it fast" saying, I'd prefer
          the reusable ones. Efficiency should be a concern, but not the primary one;
          it's enough if we *see* how to make it fast.

          Coming back to the concrete issue, I'd not bother about the number of parent
          classes; a compiler can optimize it out, and in fact this has been
          demonstrated.
          In other words, if a compiler has problems with a deep class hierarchy, I
          recommend that the vendor do his homework, not that we dumb down the class
          hierarchy. There are enough other reasons to keep the class hierarchy flat.

          Regards,
          Joachim
          --
          This is not an official statement from my employer or from NICE.
        • Greg Compestine
          alexander kogtenkov wrote: original article:http://www.egroups.com/group/eiffel-nice-library/?star t=1193 ... probably it s ... for ARRAY and
          Message 4 of 8 , Mar 30, 2000
          • 0 Attachment
            "alexander kogtenkov" <kwaxe-@...> wrote:
            original article:http://www.egroups.com/group/eiffel-nice-library/?star
            t=1193
            > Ulrich Windl wrote:
            > ...
            > > > use contiguous memory area to keep the data (Eiffel/S 1.3). So,
            probably it's
            > > > better to start from the first class, which is a common ancestor
            for ARRAY and STRING.
            > ...
            > > I wonder: Can these rather basic classes be implemented efficiently
            > > if they are descendants from a huge pile of abstract classes (like
            > > EiffelBASE's SEQUENCE)?
            >
            > It does affect the efficiency, though in most applications the
            compilers can
            > optimize the things (at least in the "boost/finalize" modes).
            >
            [snip..]

            Hmm, this touches upon a thread I started in eiffel-nice-discuss on
            ARRAY and STRING being only superficially related. One of my concerns
            is that uniting the two with a abstract parent class is that it could
            inhibit alternate implementations in the future.

            The main thing they have in common are index operations. Yet I don't
            think that's justification for linking the two via inheritance.

            I can only think of two reasons for having a common parent for two
            classes. The first is to share implementation. I believe the
            implementation for an ARRAY vs a STRING could be so different that
            there is common ground in the implementation (I provide a couple
            examples in the other thread).

            The other reason is to provide polymorphism. If you have a useful
            application for passing around ARRAYs and STRINGs by way of a common
            base class, I'd love to hear about it.

            I recommend we deliberately not address this issue. Leave it to the
            compiler implementers. If they feel its justified to link the two, then
            they can. If on the other hand, they don't want to then they shouldn't
            have to. Certainly the ELKS specification doesn't have to state whether
            the interface is entirely within the target class, or if some of it is
            derived via inheritance.

            Greg
          • Ulrich Windl
            On 30 Mar 00, at 20:03, Greg Compestine wrote: [...] ... Even if there s no polymorphism, there should be features with identical names for appending,
            Message 5 of 8 , Mar 30, 2000
            • 0 Attachment
              On 30 Mar 00, at 20:03, Greg Compestine wrote:

              [...]
              > The other reason is to provide polymorphism. If you have a useful
              > application for passing around ARRAYs and STRINGs by way of a common
              > base class, I'd love to hear about it.
              >
              > I recommend we deliberately not address this issue. Leave it to the
              > compiler implementers. If they feel its justified to link the two, then
              > they can. If on the other hand, they don't want to then they shouldn't
              > have to. Certainly the ELKS specification doesn't have to state whether
              > the interface is entirely within the target class, or if some of it is
              > derived via inheritance.

              Even if there's no polymorphism, there should be features with
              identical names for appending, truncating, searching, etc. I once had
              a case where I started an application with STRINGs in Eiffel/S 1.21
              when I found out that it could not handle '%U' transparently. I had
              to change to ARRAY[CHARACTER]. Then you appreciate it very much if
              they have similar interfaces. There should also be a convenient
              conversion between STRING and ARRAY[CHARACTER] IMHO.

              Regards,
              Ulrich



              Gruß
              Uli
            Your message has been successfully submitted and would be delivered to recipients shortly.