PROPOSAL: Auto-assignment Parameters

[Derek Foster]

Just to add a few kudos and comments:

I like the proposal a lot. Even in its current form, this would save me a lot of typing. Of the proposals so far put forth on Project Coin, this is the one I would probably end up using the most often. I use a lot of immutable class objects, and this 

Some suggestions and things to consider:

1) I think that having to repeat "this." all over the place is perhaps unnecessary. You could use something shorter, like a leading dot, or perhaps a leading equals sign:

class Foo {
   final int bar;
   final String baz;
   Foo(int .bar, String .baz) {}
   void setBar(int .bar) {}
   void setBaz(String .baz) {}
}

2) I think that allowing the syntax for all method parameters, not just constructor parameters, would be nice.

3) I think that allowing the syntax for return values from methods has some potential advantages as well. There are some potential advantages with
Javadoc generation, as I describe below, which would make:

    String this.foo getFoo() {}

advantageous in some circumstances even if it isn't much shorter than:

    String getFoo() { return this.foo; }

4) I think you should consider the impact on Javadoc more carefully. Particularly in cases where people use a prefix ("_", "m_", etc.) on their internal fields, which is very common. It looks as though those prefixes would end up being displayed in Javadoc as constructor parameter names, which would be less than ideal.

Also, autogeneration of Javadoc for the this. parameters, based on Javadoc for the class members they are initialized from would be nice. Currently, these often have to be maintained in parallel, which can be a significant annoyance. 

I often see people write code equivalent to:

class Foo {
    /** This is the name of a famous person which can't be null and blah blah blah. */
    String _bar;

    /**
     * Construct a new instance.
     * @param bar This is the name of a famous person which can't be null and blah blah blah. 
     */
    Foo(String bar) {
        _bar = bar;
    }

    /**
     * Sets the value of bar.
     * @param bar This is the name of a famous person which can't be null and blah blah blah. 
     */
    void setBar(String bar) {
        _bar = bar;
    }

    /**
     * Gets the value of bar.
     * @return This is the name of a famous person which can't be null and blah blah blah. 
     */
    String getBar() {
        return _bar;
    }

}

which essentially reproduces the same JavaDoc comment four times (and means it must be maintained in quadruplicate if changes are made). It would be nice to replace this with something like:

class Foo {
    /** This is the name of a famous person which can't be null and blah blah blah. */
    String _bar;

    /** Construct a new instance. */
    Foo(String this.bar) {}

    /** Sets the value of bar. */
    void setBar(String this.bar) {}

    /** Gets the value of bar. */
    String this.bar getBar() {}
}

with the same Javadoc being generated as the prior example.

5) Being able to omit the type in all of these cases would be a big plus. When I have a variable of a type like "List<Map<ReallyLongTypeName,OtherReallyLongTypeName>>", it would be awfully nice to be able to omit having to specify that detail redundantly in the constructor, settter, and getter.

Derek




-----Original Message-----
>From: Mark Mahieu <markmahieu at googlemail.com>
>Sent: Mar 26, 2009 2:21 PM
>To: Marek Kozieł <develop4lasu at gmail.com>
>Cc: coin-dev <coin-dev at openjdk.java.net>
>Subject: Re: PROPOSAL: Auto-assignment Parameters
>
>2009/3/26 Marek Kozieł <develop4lasu at gmail.com>
>
>> I see one problem here.
>> class Some{
>>   final String name;
>>   public Some(String this.name){}
>> }
>>
>> perform .intern() is impossible now.
>
>
>Correct, you'd have to write it the same way as you'd do now.  I actually
>view that as a Good Thing though: there's a clear, visual distinction
>between parameters which are just assigned directly to the fields, and those
>on which we perform some operation first.  Only the latter would appear in
>the body of the constructor, without being cluttered by the former.
>
>
>> But I like the proposition 'much'.
>> Simple and clear.
>
>
>Glad you like it!
>
>
>Regards,
>
>Mark
>