PROPOSAL: Auto-assignment Parameters

[Derek Foster]

-----Original Message-----
>From: Mark Mahieu <markmahieu at googlemail.com>
>Sent: Mar 29, 2009 6:18 AM
>To: Derek Foster <vapor1 at teleport.com>
>Cc: coin-dev at openjdk.java.net
>Subject: Re: PROPOSAL: Auto-assignment Parameters
>
>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.
>...
>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?

Sorry for taking so long to answer this... it took me a while to find this message again.

Anyway, I might consider dropping the prefix, IF this proposal specified one thing that I'm not sure that it does, in it's current form.

Specifically, what my prefix use is intended to protect against is name shadowing: cases where there is a local name (a parameter name) which is identical to the same name in an enclosing scope (a field name). This scenario has caused a great deal of grief to a great many people. Hence, I try to force my names in different scopes to be different, to avoid the possibility of shadowing.

Whether this proposal improves this situation depends on whether this:

void Foo(this.bar) {

    bar = whatever;
}

sets the field 'bar' to 'whatever', or whether it sets the parameter 'bar' to 'whatever'. If the latter is true, then there is still name shadowing going on, and I would still be inclined to use a prefix. If the former is true, which I would prefer (if 'this.bar' in a formal parameter list does not actually introduce a new named parameter instance into the local scope) then I would probably not feel a continued need for a prefix, at least in this case.

Note, however, that there are still lots of cases that aren't covered by your proposal that might make a prefix desirable, such as:

void setFoo(Thing foo) {
    lock();
    try {
         _foo = foo;
    } finally {
         unlock();
    }
}

I don't see an easy way to extend your proposal to cover such a case.

Derek








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