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

Re: [eiffel-nice-library] Re: STRING: append/insert/remove comman ds

Expand Messages
  • Eric Bezault
    ... Also note that the postconditions of `insert_character and `insert_string are different. Merging these routines into a single `insert (other: ANY) will
    Message 1 of 7 , Aug 31, 2000
      Roger Browne wrote:
      > On the other hand, if we _only_ have "insert(other: ANY)" then the most
      > common operations of inserting a CHARACTER or a STRING become
      > considerably slower -

      Also note that the postconditions of `insert_character' and
      `insert_string' are different. Merging these routines into
      a single `insert (other: ANY)' will result in the lost of
      their postconditions.

      --
      Eric Bezault
      mailto:ericb@...
      http://www.gobosoft.com
    • Roger Browne
      ... i.e.: insert (STRING) insert_character (CHARACTER) append (STRING) append_character (CHARACTER) Of these features: insert is in ELKS, and is
      Message 2 of 7 , Sep 1 6:39 AM
        Dave Martin wrote:

        > ... as you say, strings know about strings and their building
        > blocks, characters, so it might be reasonable to have inserts for just
        > the two types, and not make string responsible for knowing about any
        > datatypes which arent strings or components thereof. In that case, I
        > would say that the naming convention of insert (STRING) and
        > insert_character (CHARACTER) would be appropriate, since it would make
        > sense to assume that an unqualified insert would insert another string...

        i.e.:

        insert (STRING) insert_character (CHARACTER)
        append (STRING) append_character (CHARACTER)

        Of these features:

        'insert' is in ELKS, and is supported by ISE/HACT/VE - but
        'insert_character' is in ELKS, and supported by HACT and VE.
        SE uses 'insert' to insert a CHARACTER.
        'append' is not in ELKS, but is supported by all vendors.
        'append_character' is in ELKS, and supported by all vendors.

        > ...(or another instance of the same type, to generalize it to any data-
        > structure-like class). I'm almost tempted to suggest insert_component
        > or insert_element instead of insert_character...

        The name to use would surely be 'insert_item', as we already have 'item'
        to retrieve an element (in STRING and ARRAY).

        On the other hand, consider:

        insert_string (STRING) insert_character (CHARACTER)
        append_string (STRING) append_character (CHARACTER)

        Of these features:

        'insert_string' is not in ELKS, and is not supported by any vendor
        'insert_character' is in ELKS, and supported by HACT and VE.
        'append_string' is in ELKS and supported by all vendors
        'append_character' is in ELKS, and supported by all vendors

        This naming scheme would also be consistent with class STD_FILES, which
        contains the following features:

        last_string (STRING) last_character (CHARACTER)
        put_string (STRING) put_character (CHARACTER)

        > Basically, other types should provide conversion to and from string if
        > they are interested in textual representation, especially since
        > general provides for this (at least conversion to) anyway.

        I agree.

        > Hm, upon reviewing your post and my response, I realize you may be
        > suggesting insert_string (STRING), insert_character(CHARACTER), and
        > insert (ANY), as a solution...

        No, I did not intend to suggest that. I do not see a need for insert
        (ANY). But if three or more others see the need, we will vote on it.

        Regards,
        Roger
        --
        Roger Browne - roger@... - Everything Eiffel
        19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
      • Dave E Martin, XXIII
        Oh, oh! continuing discussion! 8) Roger Browne wrote: [...] ... Well, frankly, if it were to only come down to these considerations, I think SE needs to be
        Message 3 of 7 , Sep 4 12:57 PM
          Oh, oh! continuing discussion! 8)

          Roger Browne wrote:

          [...]

          > 'insert' is in ELKS, and is supported by ISE/HACT/VE - but
          > 'insert_character' is in ELKS, and supported by HACT and VE.
          > SE uses 'insert' to insert a CHARACTER.
          > 'append' is not in ELKS, but is supported by all vendors.
          > 'append_character' is in ELKS, and supported by all vendors.

          Well, frankly, if it were to only come down to these considerations, I think
          SE needs to be the one to take in the shorts, as they are claiming they are
          trying to conform to ELKS, but didn't in this case; and we're basically being
          'nice' (stop groaning) by trying to take non-compliant implementations into
          account anyway.


          > This naming scheme would also be consistent with class STD_FILES, which
          > contains the following features:
          >
          > last_string (STRING) last_character (CHARACTER)
          > put_string (STRING) put_character (CHARACTER)

          Now, here, one could point out that in the case of STD_FILES 'last' and 'put'
          would not put a string, they would put another instance of STD_FILE (if such a
          feature existed); here the _string name is appended because it is not the
          'default' type for those classes.


          Ignacio Calvo generated the following disturbances in the energy structure of
          the universe:

          >Other option is:

          > insert (s: like Current)
          > insert_string (s: STRING)

          >directly in STRING. Same effect, but forces the descendants to
          >use the current type with 'insert', which I think is the most
          >default action in the descendants.

          >Saludos from Spain! Ignacio Calvo
          >e-mail: icalvo@...

          This has a certain appeal as well, and kinda goes along with some of the other
          classes, which provide more than one entry point for the same functionality,
          depending on what guarantees the client is looking for; would we want to add
          'frozen' to insert_string in this case? This also ensures that insert would
          continue to insert the 'current' (default) type. On the other hand maybe this
          is overkill, maybe not? How flexible do we want to be, considering canned
          worms and all?

          Discuss?

          --
          <*> -- Know Future
          Equality, coming soon to a democracy near you; the tide is rising.
        Your message has been successfully submitted and would be delivered to recipients shortly.