PROPOSAL: Auto-assignment Parameters

[Reinier Zwitserloot]

Derek, if this proposal will save you a lot of typing, I think you're  
doing it wrong. Thare are many tools that will auto-generate POJOs for  
you, including whatever setter you prefer. Most IDEs have this in  
their 'source' or 'refactor' menu, for example.

What annoys me about these tools is that they are one-way operations.  
 From seeing the multiple pages of POJO auto-generated code (incl.  
hashCode, equals, toString, and constructor, and in some cases, the  
auto-generated builder as well), I cannot ascertain quickly if this is  
'just' the usual auto-generated boilerplate, or if there's a fun  
surprise in there someplace (like some field being excluded for equals/ 
hashCode purposes, or a missing getter, or some such). This makes  
POJOs spectacularly unmaintainable compared to the low impact they  
should be having, in java. It's also somewhat difficult (but certainly  
not impossible) to change things that were used to auto-generate code,  
such as changing the type or name of a field later.

That's why I want a 'data' modifier for class, which will completely  
auto-generate everything. If the 'saves me typing' argument holds  
water, imagine what this will do for you! I also don't want such a  
feature to spin out of a control into an entirely new programming  
definition syntax, so we'll just use java itself to fill in the gaps  
and afford us flexibility: If the auto-gen isn't good enough for you,  
then don't use it and write it the usual way. You get method-level  
granularity for this process, but that's where it ends. Simple and yet  
a great boon for code maintainability.



  --Reinier Zwitserloot



On Mar 28, 2009, at 22:31, Derek Foster wrote:

> 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
>>
>
>