PROPOSAL: Auto-assignment Parameters

[Mark Mahieu]

On 28 Mar 2009, at 21: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.

Hi Derek,

That's very encouraging to hear.  Thanks!


> I use a lot of immutable class objects, and this

Your sentence got cut off, but this proposal came about while writing  
an immutable class, and accidentally initializing a field from the  
wrong parameter (the joys of copy/paste).


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

The majority of my colleagues preferred 'this.' as it's meaningful  
and quite short but still stands out enough to say "I'm not just a  
normal parameter!".  There are other options though, if the wider  
consensus turned out to be different.

I wouldn't favour a dot, personally - it might be a little too easy  
to miss.  Syntax highlighting wouldn't help either, as a red, italic  
dot still looks much the same as any other dot ;)


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

A number of people have expressed that wish.  It's certainly a  
possibility, and doesn't change very much in terms of the proposal's  
details - the grammar would change the most (it could be simpler in  
that case).

I imagine it might encourage people to employ the Builder pattern  
more often (Effective Java 2nd Ed., Item 2), which would be a good  
thing I think.


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

Defining appropriate semantics seems less straightforward for return  
values than for parameters, if there are also statements in the  
method body.  For example, should early return statements be allowed  
in the method body?  If so, can they only return the declared value?


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

I wouldn't expect people to change publicly exposed parameter names  
to reflect the implementation details of their classes - it should be  
the other way around, or not at all.

I hijacked javac to gather some statistics across of a number of  
large, currently active code-bases, and prefixes seem to be very much  
the exception rather than the norm.

More common are cases where there's no prefix, but the field and  
parameter names are different for other reasons.  Some of these look  
like good choices, but quite a number seem to have very good field  
names, and poor parameter names which would be improved if they did  
adopt the same name as the corresponding field!

Either way, they're all vastly outnumbered (in the source I've  
analysed so far) by parameters which do have the same name as the  
field to which they're assigned, as noted in Java Puzzlers (page 181).

It would be possible to extend the proposal to allow the field name  
to be specified along with an (optional) alternative parameter name.   
I'm just not sure the added complexity would be justified, although  
such a change could also conceivably happen in a later release if  
evidence were to stack up in its favour.

In one of your other emails to this list, you mentioned that you use  
a prefix on field names to prevent typographical mistakes.  Given  
that this proposal aims to avoid many of the situations in which  
those mistakes can be made, would you continue to do so if it were  
implemented?


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

That's an interesting idea, though perhaps best suited to a language  
feature directly supporting properties, if one is implemented.   
Whether it could fit in here would depend on a number of factors, but  
it's worth bearing in mind.


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

When I tried that, I found that it worked reasonably well for simple  
(ie. very small) classes, but didn't scale well; my ability to  
comprehend the code decreased as the class increased in size.  Also,  
including the type in the parameter declaration makes it clear that a  
local variable is being introduced into the scope of the constructor/ 
method body, just like a normal formal parameter.  Finally, omitting  
the type places restrictions upon the order in which a tool such as  
javac can choose to process Java source, which is something I'd  
rather avoid if possible.


Thanks for all your comments!


Regards,

Mark