PRE-PROPOSAL: Named method parameters with defaults.

[Reinier Zwitserloot]

1. [problems with determining correct method signature] Not a (new)  
problem - that's a problem of overloading in general. Names help, if  
anything. Also one of the reasons for my suggestion to only allow  
'named' on one method in a stack of overloads. Also: that's why the  
'named' keyword is required and why there is no default 'everything is  
named' option. Old code uses no names -> no defaults either -> no  
issues with existing code that has much overloading with ample  
opportunity for ambiguous invocations if defaults are introduced.

2. [What happens if defaults change?] Changing default value is fine  
of course - they are stored in fields in the same class as the method.

3. [Builder pattern still needed because of order] But you CAN change  
the order.

  --Reinier Zwitserloot



On Mar 23, 2009, at 00:36, Marek Kozieł wrote:

> 1. Problems:
> - in notation suggested by you, compilator and people may find problem
> with determining valid method signature (when we have few methods with
> same names)
>   Same as now time:
>      void a(Boo boo);
>      void a(String booName);
>   call:
>      .a((String) null);
>   now imagine that Boo is generic ...
>
> - when some one would change default value (how already compiled code
> should react?), that why i think that values should be stored on
> special static fields.
>
> 2. Some solution could bring keeping parameter blank for default  
> value:
> foo(,"bar"); // first is default;
> foo("bar",); // second is default;
>
> 3. Genesis
> If you think that this can replace builders, then in my opinion you  
> are wrong.
> When class need so many parameters, so it become problem to list them
> in proper order, then obtaining those data is also problem, so even if
> we will have named parameters 'generally' problem will do not
> decrease.
> I found it while I created some library:
>   It become common for peoples that while it was hard for them to
> collect all data at once they produces their own builders, so at end,
> to many parameters mean that in each dependent project someone will
> create it's own builder, and it's no mater, if they will be able to
> call parameters by names, or not.
>
> -- 
> Pozdrowionka. / Regards.
> Lasu aka Marek Kozieł
>
> http://lasu2string.blogspot.com/
>