PROPOSAL: Auto-assignment Parameters

[Derek Foster]

-----Original Message-----
>From: Reinier Zwitserloot <reinier at zwitserloot.com>
>Sent: Mar 31, 2009 9:05 AM
>To: Derek Foster <vapor1 at teleport.com>
>Cc: coin-dev at openjdk.java.net
>Subject: Re: PROPOSAL: Auto-assignment Parameters
>
>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.

It wasn't the typing of creating them in the first place that I had in mind, but what comes after that.

I would explain more on that point, but it seems you have saved me the trouble:

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

You and I are in rabid agreement on that point. I don't like code generation tools that spew forth blocks of code that I then have to maintain. To me, the existence of such tools indicates a deficiency in the language. (If it's easy enough for a tool to generate boilerplate code like that, it should be easy for the language to make that boilerplate code unnecessary by generating it for me as I compile.)

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

We agree on this. I want a data modifier for a class also (or could we just use the 'struct' keyword like C++?). However, the auto-assignment parameters proposal has more general applicability to classes other than data classes as well, so I want those too. I might even use them both together in the same class.

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

I agree with this as well. I think it's perfectly reasonable for there to be shorthand syntax for common cases, with the ability to override it when something more complex is needed. If I just want to return three values from a method, I don't want to have to write a full-blown class complete with a constructor, getters, and setters. Just specifying the fields is enough. A data class will probably do fine. But I want to be able to replace that data class later with the real thing if necessary without having to update all of the uses of it in the code.

Derek

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