groovy
  1. groovy
  2. GROOVY-4519

Add shorthand syntax for specifying access modifiers for property methods (setters & getters) & fields

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.8-beta-2, 3.0
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      all
    • Number of attachments :
      0

      Description

      The current Groovy bean syntax to define a public property with a public setter & getter and a private backing field is as described in http://groovy.codehaus.org/Groovy+Beans.

      I propose a new, optional syntax that allows the class author to control the access modifier of the getter method, setter method, and field. The default, if the access modifier specification is not present, would be to produce a public setter & getter with a private backing field, just as it always has been. The proposed syntax can be specified using the following symbols.

      + public (pretty intuitive)
      ~ protected (similar to Unix's "home" concept: the class's "home" package, this class or its subclasses)
      = package (the package of the accessing code must be equal to this element's package)

      • private (pretty intuitive)
        ! for getter/setter only: tells compiler not to generate method (common negation symbol)

      I propose that the scope specifier expression is of the following form:

      [<setterAccessSpecifier><getterAccessSpecifier><fieldAccessSpecifier>]

      (square brackets indicate optional elements). The most common use cases outside Groovy's current default are those with a non-public setter, a public getter, and a private field.

      I invite discussion on whether it should be a compiler error if the field specifier were ever more accessible than or equal to the scope of the setter or getter method. Basically, it might require callers in different packages to use @field syntax; I leave that consideration to the Groovy compiler experts.

      While the proposed form could be modified to make getter & field access specifications optional, making it terser, it also might be less intuitive, especially if specifying a non-public scope for the setter or when not generating a setter method. While the proposed form is more verbose, it does have the advantage of being pretty explicit, once you know that the order is setter-getter-field, and the class author, if choosing to specify something other than public/public/private, is already stepping a bit outside the box.

      The default value of the access specifier is "++-".

      Here are some examples:

      class Person {
        String name // public setter & getter, private field; same as ++-
      }
      

      =====

      class Person {
        ++- String name // public setter & getter, private field; same as current Groovy compiler
      }
      

      =====

      class Person {
        ~+- String name // common:  protected setter, public getter, private field
      }
      

      =====

      class Person {
        -+- String name // common:  private setter, public getter, private field
      }
      

      =====

      class Person {
        !+- String name // no setter, public getter, private field
      }
      

      =====

      class Person {
        --+ String name // ERROR?  private setter, private getter, public field
      }
      

      =====

      class Person {
        ++~ String name // public setter, public getter, protected field
      }
      

        Issue Links

          Activity

          Hide
          Matthew Adams added a comment -

          Code examples got dorked by JIRA formatting – sorry. They were three-liners.

          Show
          Matthew Adams added a comment - Code examples got dorked by JIRA formatting – sorry. They were three-liners.
          Show
          Matthew Adams added a comment - Mailing list thread is at http://groovy.329449.n5.nabble.com/Add-shorthand-syntax-for-specifying-access-modifiers-for-property-methods-setters-getters-fields-tp3273659p3273659.html
          Hide
          Matthew Adams added a comment -

          I just noticed JIRA formatting struck again. The symbol for private was supposed to be a minus sign ("-"), but JIRA made it a bullet point. Sorry again.

          Show
          Matthew Adams added a comment - I just noticed JIRA formatting struck again. The symbol for private was supposed to be a minus sign ("-"), but JIRA made it a bullet point. Sorry again.
          Hide
          Andrew Eisenberg added a comment -

          fixed formatting.

          Show
          Andrew Eisenberg added a comment - fixed formatting.
          Hide
          blackdrag blackdrag added a comment -

          What Groovy can do right now is using the final keyword to avoid the creation of a setter, but besides that only public for the getter/setter and private for the field is regarded, that is true... And that is because we wanted it to be according to the bean specification back then.

          I would encourage making this an AST transform first. the example

          class Person {
            ~+- String name // common:  protected setter, public getter, private field
          }

          would then be

          class Person {
            @Property("~+-")
            String name // common:  protected setter, public getter, private field
          }

          The advantage of using an transformation is that it does not require any changes to the compiler and that we have some code to test

          Show
          blackdrag blackdrag added a comment - What Groovy can do right now is using the final keyword to avoid the creation of a setter, but besides that only public for the getter/setter and private for the field is regarded, that is true... And that is because we wanted it to be according to the bean specification back then. I would encourage making this an AST transform first. the example class Person { ~+- String name // common: protected setter, public getter, private field } would then be class Person { @Property( "~+-" ) String name // common: protected setter, public getter, private field } The advantage of using an transformation is that it does not require any changes to the compiler and that we have some code to test
          Hide
          Hamlet D'Arcy added a comment -

          I am sorry, but I don't like this proposal. This annotation is an abbreviation and not an abstraction. It does not limit the number of concepts you need to know in order to write the proper code, in fact it increases the number of concepts. If anything, I would follow the C# syntax because at least the syntax is self describing. But still, we're not really adding anything to the language here.

          We should either close this JIRA or move it to the transforms module.

          Show
          Hamlet D'Arcy added a comment - I am sorry, but I don't like this proposal. This annotation is an abbreviation and not an abstraction. It does not limit the number of concepts you need to know in order to write the proper code, in fact it increases the number of concepts. If anything, I would follow the C# syntax because at least the syntax is self describing. But still, we're not really adding anything to the language here. We should either close this JIRA or move it to the transforms module.
          Hide
          Guillaume Laforge added a comment -

          I agree with Hamlet here, and with other commenters.
          It's not very much in line with the usual syntax of Groovy (a taste of Perl? or Objective-C) and feels a bit foreign.
          So it won't be integrated into Groovy. But that would certainly be a worthwhile contribution to the Groovy Modules if so desired for people interested in this approach.

          Show
          Guillaume Laforge added a comment - I agree with Hamlet here, and with other commenters. It's not very much in line with the usual syntax of Groovy (a taste of Perl? or Objective-C) and feels a bit foreign. So it won't be integrated into Groovy. But that would certainly be a worthwhile contribution to the Groovy Modules if so desired for people interested in this approach.

            People

            • Assignee:
              Unassigned
              Reporter:
              Matthew Adams
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: