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

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

Expand Messages
  • Simon Parker
    Good evening. (Warning: contains waffle, reminiscence and opinion :-) I have always suspected that the similarities between STRING and ARRAY[CHARACTER] were
    Message 1 of 1 , Apr 5, 2000
    • 0 Attachment
      Good evening.

      (Warning: contains waffle, reminiscence and opinion :-)

      I have always suspected that the similarities between STRING and
      ARRAY[CHARACTER] were illusory, yet in practical terms it's been useful so
      often I can't bring myself to separate them completely.

      This fascinating discussion reinforces my misgivings, and I wonder whether
      the compulsive desire to index into a STRING is born of too much sorting,
      searching and pattern-matching with re-invented algorithms. I recall being
      startled when, (emerging from a COBOL, BASIC and assembler) I discovered
      that C strings were character arrays.

      Mostly I would like to concatenate STRINGs and compare them for equality.
      They do need to be sortable, though I should be happier to see that aspect
      separated from the basic abstraction. For other applications like parsing
      or pattern matching I should like library support, and I wouldn't care if
      the result came back as a memento or cursor rather than an INTEGER. In
      other words, I can live without an integer index most of the time. If a
      vendor suggests that a more efficient implementation is possible I'll
      surrender it.

      In exchange, however, I should look for something I miss in the present
      class: easy conversion between STRING and ARRAY [CHARACTER]. Then I could
      manipulate the characters with the full power of ARRAY when I need to, and
      convert back again when I've finished.

      So, I endorse Ulrich's appeal. Here's a tentative specification for a pair
      of features.

      make_from_array (source: ARRAY [CHARACTER])
      -- Load all the characters from 'source' in the same order
      require
      source_present: source /= Void
      ensure
      same_length: count = source.count
      same_head: is_empty or else item (1).is_equal (source.item
      (source.lower))
      -- same_tail: (recursive specification omitted...)
      end -- make_from_array

      as_array: ARRAY [CHARACTER]
      -- Array containing all characters in string
      -- in the same order
      ensure
      base_1: Result.lower = 1
      same_length: Result.count = count
      same_head: is_empty or else item (1).is_equal (Result.item (1))
      -- same_tail: (recursive specification omitted...)
      end -- as_array

      The type of character could perhaps be anchored
      make_from_array (source: ARRAY [like item])
      or we could provide a new pair
      make_from_unicode_array (source: ARRAY [UNICODE_CHARACTER])
      as_array: ARRAY [UNICODE_CHARACTER]
      depending on the outcome of another debate.



      On Friday, March 31, 2000 7:22 AM, Ulrich Windl
      [SMTP:Ulrich.Windl@...-regensburg.de] wrote:
      > 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
      >
      > ------------------------------------------------------------------------
      > ---------------------------
      > http://www.eiffel-nice.org/
      > --------------------------
      >
      > ------------------------------------------------------------------------
      > Special Offer-Earn 300 Points from MyPoints.com for trying @Backup
      > Get automatic protection and access to your important computer files.
      > Install today:
      > http://click.egroups.com/1/2344/0/_/1718/_/954483722/
      >
      > -- Easily schedule meetings and events using the group calendar!
      > -- http://www.egroups.com/cal?listname=eiffel-nice-library&m=1
      >



      Regards,
      Simon

      Simon Parker +353 87 249 7859
    Your message has been successfully submitted and would be delivered to recipients shortly.