Accumulo
  1. Accumulo
  2. ACCUMULO-477

inconsistent names and duplicate methods in IteratorSettings

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.4.0
    • Component/s: client
    • Labels:
      None

      Description

      David Medinets noticed

      A Property object used to hold key-value information used to modify
      the behavior of an Interator. However, these are the methods
      available:

       getProperties
       setProperties
       hasProperties
       addOption
       removeOption
       addOptions
       clearOptions
      

      Is there a reason why the same concept as two names? I'd like to
      settle on one name and standardise.

      Could we change the names to be something like
      getInteratorSettingProperties? I know that some people are annoyed by
      longer method names, but when searching through a code base, have
      unique names is handy. Searching for a generically named method - such
      as getProperties, returns a lot of false positives.

        Activity

        Hide
        Eric Newton added a comment -

        Yes, we would remove them in 1.5. I'll fix the javadoc (thanks!)

        Show
        Eric Newton added a comment - Yes, we would remove them in 1.5. I'll fix the javadoc (thanks!)
        Hide
        Billie Rinaldi added a comment -

        What does deprecated since 1.4.1 imply? Does that mean we would remove the methods in 1.5?

        Also, the javadocs are incorrect. Syntax for methods is Classname#methodName (or just #methodName if it's the current class), and there's a link to a method that doesn't exist (setOptions presumably should be addOptions).

        Show
        Billie Rinaldi added a comment - What does deprecated since 1.4.1 imply? Does that mean we would remove the methods in 1.5? Also, the javadocs are incorrect. Syntax for methods is Classname#methodName (or just #methodName if it's the current class), and there's a link to a method that doesn't exist (setOptions presumably should be addOptions).
        Hide
        Eric Newton added a comment -

        I responded:

        I don't know why there are duplicate methods for the same concept.

        I propose we add getOptions, and deprecate getProperties, setProperties, hasProperties.

        And getOptions should return an unmodifiable map.

        I disagree about the generic names; I like short names. Eclipse finds references pretty well.

        Show
        Eric Newton added a comment - I responded: I don't know why there are duplicate methods for the same concept. I propose we add getOptions, and deprecate getProperties, setProperties, hasProperties. And getOptions should return an unmodifiable map. I disagree about the generic names; I like short names. Eclipse finds references pretty well.

          People

          • Assignee:
            Eric Newton
            Reporter:
            David Medinets
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development