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

[eiffel-nice-library] Re: ARRAY 'lower' and 'upper'

Expand Messages
  • Ulrich Windl
    ... TowerEiffel s eshort had an optional feature summary . Ulrich
    Message 1 of 20 , Jan 6, 2000
    • 0 Attachment
      On 5 Jan 00, at 21:01, Durchholz, Joachim wrote:

      > > From: Arno Wagner [mailto:wagner@...-trier.de]
      > >
      > > I think there should be a standardized feature commentwith every such
      > > primitive. But I think also that a short list of all the primves
      > > at the beginning of the class would serve as an useful of quick
      > > orientation about the data-type structure.
      >
      > I'd say either-or. Keeping the same information in two places is just going
      > to produce inconsistencies.

      TowerEiffel's eshort had an optional "feature summary".

      Ulrich
    • Simon Parker
      Good morning. ... [...] ... primitive sounds like the right adjective to me. specifier sounds ugly, but does convey the intent more explicitly than query
      Message 2 of 20 , Jan 7, 2000
      • 0 Attachment
        Good morning.

        On Wednesday, January 05, 2000 7:37 PM, Durchholz, Joachim [SMTP:Joachim.Durchholz@...] wrote:
        > James McKim wrote on feature layering:
        >
        [...]
        > > Richard Mitchell has suggested "primitive query" (not in this
        > > list, don't go looking for it).

        'primitive' sounds like the right adjective to me.
        'specifier' sounds ugly, but does convey the intent more explicitly than 'query' or 'feature'. Any of those would do, though.

        Regards,
        Simon

        Simon Parker +353 87 249 7859
      • Durchholz, Joachim
        ... If we assume tool support, the point becomes moot: The tool doesn t need any comments, it will just parse the features and retrieve any information from
        Message 3 of 20 , Jan 7, 2000
        • 0 Attachment
          > From: James McKim [mailto:jcm@...]
          >
          > Joachim Durcholz wrote:
          > >
          > > James McKim wrote on feature layering:
          > >
          > > > It'd be better if we could display the actual graph so a
          > > > reader could see, for example, that
          > > >
          > > > 1. `valid_index' depends only on `lower' and `upper'.
          > > > 2. `make' depends only on `lower', `upper' and `all_default'
          > > > 3. Only `make', `force' and `resize' depend on `all_default'
          > > >
          > > > and so on. But I think it would probably take some tool support to
          > > > do that well.
          > >
          > > This looks attractive.
          > >
          > > I'm not sure that the entire graph should be depicted
          > > (after all, some links
          > > are less important than others). It should be possible to
          > > give a full graph
          > > of feature groups though, and that would be really useful.
          >
          > Taking tool support as an axiom, I wouldn't want to omit the
          > possibility of looking at the whole graph.

          If we assume tool support, the point becomes moot: The tool doesn't need any
          comments, it will just parse the features and retrieve any information from
          there.
          Comments should be mandatory only for information that cannot be
          automatically gathered. (This is a variant of the "no redundancies" policy.)

          Regards,
          Joachim
          --
          This is not an official statement from my employer or from NICE.
        • Durchholz, Joachim
          ... This doesn t combine well with feature categories like Access etc. Besides, a feature can change its basicality status in a subclass, meaning that you
          Message 4 of 20 , Jan 7, 2000
          • 0 Attachment
            > How about grouping these features under a header comment
            > something like this:
            >
            > feature -- Basic queries
            > -- All other queries are (ultimately) defined in terms
            > -- of these queries.
            > -- All commands are (ultimately) defined in terms of
            > -- their effect on these queries.

            This doesn't combine well with feature categories like "Access" etc.
            Besides, a feature can change its "basicality" status in a subclass, meaning
            that you cannot use feature categories for clients.

            I still opt for either a class header comment or for feature comments, with
            a preference for the feature comment because class header comments will tend
            to get out of sync with what's really happening within the class (not a
            factor for ELKS, but we want to set up the ELKS code in a way that's useful
            for programmers in the trenches as well).

            Regards,
            Joachim
            --
            This is not an official statement from my employer or from NICE.
          • Durchholz, Joachim
            ... I d stick with feature (regardless of adjective). We already have too much special terminology floating around in the Eiffel community. Regards, Joachim
            Message 5 of 20 , Jan 7, 2000
            • 0 Attachment
              > 'specifier' sounds ugly, but does convey the intent more
              > explicitly than 'query' or 'feature'. Any of those would do, though.

              I'd stick with "feature" (regardless of adjective). We already have too much
              special terminology floating around in the Eiffel community.

              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.