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

Summary: STRING 'make_from_string'

Expand Messages
  • Roger Browne
    Here s what I see as a summary of the current discussion on STRING make_from_string : 1. The original intention was that make_from_string would be useful to
    Message 1 of 1 , May 12, 2000
    • 0 Attachment
      Here's what I see as a summary of the current discussion on STRING

      1. The original intention was that 'make_from_string' would be
      useful to initialize a descendant of STRING from a STRING
      (specifically a manifest STRING).

      2. This feature is a creation feature for SE, VE and ISE but
      only a regular feature for HACT.

      3. The ISE and HACT implementations include a postcondition
      'shared_implementation' that can cause problems.

      4. ISE's own code does not depend on the shared implementation.

      5. Halstenbach's own code probably does not depend on the shared

      6. Several users think it would be a "good idea" to have
      a feature such as 'make_from_string' introduced in STRING.

      7. The ISE and HACT libraries include classes descending from
      STRING that have a 'make_from_string' creation feature
      (i.e. classes DIRECTORY_NAME and FILE_NAME).

      8. It turns out that ISE and HACT's DIRECTORY_NAME and FILE_NAME
      classes do not use the inherited 'make_from_string',
      apparently because the aliasing would cause problems.

      9. Up to this point, it seems that a good course of action
      would be to retain 'make_from_string', and forbid sharing
      of representation. However...

      10. Ignacio Calvo pointed out that a descendant such as
      DIRECTORY_NAME might need to impose a precondition on
      'make_from_string', to ensure that the supplied STRING
      was a suitable one.

      11. A descendant can only weaken preconditions, yet
      "require false" seems inappropriate for the version
      of 'make_from_string' introduced into STRING.

      I don't feel we have yet found a good solution for 'make_from_string'.

      I don't propose to vote on 'make_from_string' at this time. Instead, I'm
      going to move it to the back of the queue of features to be considered.
      When we come round to considering it again, we may possibly:

      (1) Vote to remove it from ELKS 2001 (just as we
      removed 'make_from_array' from ELKS 2000 ARRAY).

      (2) Vote to include it in ELKS 2001 (if a suitable
      specification can be found).

      But if anyone has any further ideas to post, please do so anytime.
      There's no need to wait until I reintroduce 'make_from_string' later.

      Roger Browne - roger@... - Everything Eiffel
      19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
    Your message has been successfully submitted and would be delivered to recipients shortly.