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

Re: [eiffel-nice-library] Summary: STRING 'make_from_string'

Expand Messages
  • Jeff Clark
    ... (... deleted ...) ... In the past when I have been confronted with this situation, I ve resorted to an ugly little hack like this ... make_from_string (s:
    Message 1 of 3 , May 12, 2000
      Roger Browne wrote:
      >
      > Here's what I see as a summary of the current discussion on STRING
      > 'make_from_string':

      (... deleted ...)

      > 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.

      In the past when I have been confronted with this situation, I've resorted to
      an ugly little hack like this ...

      make_from_string (s: STRING) is
      require
      s_is_valid_initializer: is_valid_initializer(s)
      do
      ...
      end

      is_valid_initializer (s: STRING) : BOOLEAN is
      -- Is `s' a valid initializer?
      do
      Result := ... -- (a)
      end

      If the class in which these features are introduced is deferred, then
      is_valid_initializer may be a deferred feature. Alternatively,
      is_valid_initializer may be effective and the statement labeled (a) would be
      "Result := True". In descendants (e.g., directory), is_valid_initializer may
      be redefined as needed to specify constraints on acceptable values of `s' for
      objects of that descendant class.

      This approach sacrifices a static (manifest) declaration of the acceptability
      of values for `s' in favor of increased flexibility. One has to look at the
      implementation of is_valid_initializer to determine whether a value for `s' is
      acceptable or not. I usually put a description of legal values (maybe a
      regular expression) in the header comment of is_valid_initializer, so that
      legal values can be determined from a "short" listing of the class.

      Note that this does allow one to violate strict DbC rules: using this
      approach, it is easy to define a valid initializer for a descendant that would
      not be legal for an ancestor (and vice versa). One needs to exercise a little
      caution when applying this technique.

      --
      Jeff Clark | SDRC Metaphase Technology Group
      "Too soon old, too late smart" | http://www.sdrc.com
      mailto:jlc@... | http://www.linuxfan.com/~jeffclark
      ------------------------------------------------------------------------------
      Microsoft's success proves "You can fool some of the people, all of the time."
    • Durchholz, Joachim
      ... Barring the possibility that I overlooked something, it s no problem to alter this for HACT. ... I missed Ignacio s post, so I ll answer this one here
      Message 2 of 3 , May 12, 2000
        > From: Roger Browne [mailto:egroups@...]
        >
        > Here's what I see as a summary of the current discussion on STRING
        > 'make_from_string':
        >
        > 2. This feature is a creation feature for SE, VE and ISE but
        > only a regular feature for HACT.

        Barring the possibility that I overlooked something, it's no problem to
        alter this for HACT.

        > 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 missed Ignacio's post, so I'll answer this one here (speaking as a private
        person now).
        I think that descendant classes that actually need a precondition might
        check this in a post-hoc fashion, by providing an 'is_valid' feature. That
        way, a DIRECTORY_NAME (or whatever) can be initialized using whatever
        string, but if parsing fails the class can record the fact and continue
        processing.
        In fact a STRING descendant that tries to guarantee syntactic properties is
        in deep trouble anyway, because each single command inherited from STRING
        would have the exactly same problem as 'make_from_string'.

        Regards,
        Joachim
        --
        This is not an official statement from my employer or from NICE.
      • Durchholz, Joachim
        ... This is not an ugly hack - it s a fully valid strategy, not just for initializers but for all features that have different preconditions in different
        Message 3 of 3 , May 12, 2000
          > From: Jeff Clark [mailto:jlc@...]
          >
          > In the past when I have been confronted with this situation,
          > I've resorted to an ugly little hack like this ...
          >
          > make_from_string (s: STRING) is
          > require
          > s_is_valid_initializer: is_valid_initializer(s)
          > do
          > ...
          > end
          >
          > is_valid_initializer (s: STRING) : BOOLEAN is
          > -- Is `s' a valid initializer?
          > do
          > Result := ... -- (a)
          > end

          This is not an "ugly hack" - it's a fully valid strategy, not just for
          initializers but for all features that have different preconditions in
          different incarnations within the inheritance hierarchy.
          The only ugliness is that introducing such a precondition changes the nature
          of the feature: it's not more self-contained, it's usefulness must be
          evaluated with respect to what some other feature says. The class is "more
          structural", and "more on a meta level": the preconditions don't talk about
          immediate values, they talk about the interrelationship of features.

          Of course, the more abstract a class, the easier it is to overlook something
          important, resulting in a class hierarchy that's worse than the original.
          But sometimes you don't have much of a choice.

          > Note that this does allow one to violate strict DbC rules: using this
          > approach, it is easy to define a valid initializer for a
          > descendant that would not be legal for an ancestor (and vice versa).

          This does not violate DbC. The new version of the class is just based on a
          different type of precondition; any clients of the class now have to check
          is_valid_initializer instead of doing some direct checks (and they need ways
          to ensure that is_valid_initializer is valid, so the change in paradigma
          does have real consequences).

          [[Phew - that's the last message in my backlog.]]

          Regards,
          Joachim
          --
          This is not an official statement from my employer or from NICE.
        Your message has been successfully submitted and would be delivered to recipients shortly.