PROPOSAL: Auto-assignment Parameters

[Vilya Harvey]

I think the general idea here is great, but I also think the original
proposal tries to be too specific about what gets auto-assigned. The
main use cases are constructors, getters and setters; so how about
just being able to declare those items as having an automatically
created implementation rather than specific parameters to them?

You could use the "default" keyword (for example) as a modifier in a
similar way to "abstract": methods and constructors declared with it
would be prevented from having a body and the compiler would provide
it instead (or report an error if it couldn't). The method bodies that
the compiler generates could be kept pretty simple. For example, this:

class Example {
    private int attr1;
    private String attr2;

    public default Example(int attr1, String attr2);
    public default int getAttr1();
    public default void setAttr1(int val);
    public default String getAttr2();
    public default void setAttr2(String val);
}

could desugar to this:

class Example {
    private int attr1;
    private String attr2;

    public Example(int attr1, String attr2) {
        super();
        this.attr1 = attr1;
        this.attr2 = attr2;
    }

    public int getAttr1() {
        return this.attr1;
    }

    public void setAttr1(int val) {
        this.attr1 = attr1;
    }

    public default String getAttr2() {
        return this.attr2;
    }

    public default void setAttr2(String val) {
        this.attr2 = val;
    }
}

The rules would be something like:
* A constructor would call super() then assign each of it's parameters
to an attribute with same name.
* A getter method would just return the value of the corresponding attribute.
* A setter method would assign the parameter value to the
corresponding attribute.

The compiler would report an error if the default modifier is misused.
For example:
* Using it on a method whose name doesn't match the rules for a getter
or a setter
* Using it on a method whose name does match the getter/setter rules,
but for which there's no corresponding attribute.
* Using it on a constructor where any of the parameter names do not
correspond to the name of assignable attribute.

I wouldn't suggest extending this to cover getters and setters for
indexed or bound properties, at this stage. You could imagine
extending this to cover default implementations of equals and hashCode
too, but that might also be a step too far. As is, I think it would
cover the majority of the use cases while keeping it conceptually
simple for users of Java (and hopefully simpler to implement as well).
What do the rest of you think?

Vil.


2009/3/27 Mark Mahieu <markmahieu at googlemail.com>:
> On 27 Mar 2009, at 00:22, Marek Kozieł wrote:
>>
>> We can also consider:
>>
>>   {
>>      private String name;
>>
>>      public this setName (String this.name){};
>>
>>      public this.name String getName(){};
>>    }
>>
>> While we have quite similar idea, they work really great with each
>> other. I just still wander if that should go so far.
>
>
> I think you're right to question whether this would be going too
> far.  Looking at the getter method, I don't see a clear gain over the
> way it would currently be written, ie,
>
>        public this.name String getName() {}
>
> doesn't strike me as a definite improvement on:
>
>        public String getName() { return name; }
>
>
> So far, the only extension to the proposal which looks like it might
> be reasonable, is simply to allow it for method parameters in
> general.  I'm not convinced that it would be worthwhile, but for the
> sake of illustration here's the example again if that option were taken:
>
>        private String name;
>
>        public void setName(String this.name) {}
>
>        public String getName() { return name; }
>
>
> In this variation, the method name, field, and type are each
> mentioned once for the getter, and once for the setter, with no need
> to mention extra variables.  Improving on that would almost certainly
> require language support for properties in general, which isn't what
> this proposal is about (and isn't in scope for Coin).
>
> Thanks for sharing your thoughts.
>
> Regards,
>
> Mark
>
>
>