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

Re: [eiffel-nice-library] ARRAY is a kernel class.

Expand Messages
  • Ulrich Windl
    ... OK. ... IMHO, STRING and ARRAY[CHARACTER] should be mostly similar. If I can insert and remove characters from STRINGS, why not doing so with elements in
    Message 1 of 2 , Jun 23, 2002
    • 0 Attachment
      On 21 Jun 2002, at 0:59, Franck Arnaud wrote:

      >
      > > Could you be more specific? Which GOBO class?
      >
      > DS_ARRAYED_LIST if you want ARRAY storage of an integer
      > indexed list.

      OK.

      >
      > > Besides of that, do you really think a generic insert routine is that
      > > bad for ARRAY? OK, it's frquently done at CS exercises, but I've
      > > already shown that I can do it.
      >
      > I think one point for the current situation is that ARRAY is
      > a basic building block for fixed size blocks, which is in
      > the kernel because it benefits from the compiler having
      > a special knownledge of it (or some internal implementation)
      > for optimisations, and ARRAY is the portable interface to
      > these optimisable features.

      IMHO, STRING and ARRAY[CHARACTER] should be mostly similar. If I can
      insert and remove characters from STRINGS, why not doing so with
      elements in ARRAY. I see that possible storage reallocation may cause
      problems, but is it really necessary to restrict functionality because
      of that.

      I could live with a BASIC_ARRAY that only has very basic features and
      an ARRAY that inherits from BASIC_ARRAY. I think even kernel classes
      should be attractive to some point.

      >
      > Beyond that I don't think you're much expected to use it
      > directly (I think I hardly ever use it except for constant
      > arrays--<<x,y>>) and datastructure libraries do provide more
      > sophisticated data structures built on it.

      I tried to stick to the standard as much as possible.


      >
      > That's a good reason not to put convenience features in ELKS,
      > because where do you stop? Today insertion, tomorrow automatic
      > resizing, next day cursors, and then you get the whole of a
      > data structure library, which is outside the kernel remit.

      inserting is more than convenience IMHO.

      >
      > Your particular request may be a bit borderline and close to
      > acceptable, but I hope my explanation helps understand why
      > it is the way it is (or at least my understanding of it).

      I understand your point.

      Regards,
      Ulrich
    Your message has been successfully submitted and would be delivered to recipients shortly.