PRE-PROPOSAL: Named method parameters with defaults. (original) (raw)

Paul Martin paul.martin at gmail.com
Sun Mar 22 15:28:10 PDT 2009

Hi,

I just don't see much value in named parameters without having defaults (or using them to choose between overloads, but that would require massive changes). Defaults without named parameters does have interesting use cases, but withOUT named parameters, you add two extra complications that do NOT exist if you force-combine them with named parameters:

I'm particularly interested in using named parameters to help call constructors or factory methods of immutable classes, where a number of final member variables need to be set. The named parameters help describe the calls, and in this case default parameters would not necessarily be needed. Certainly named parameters and defaults affect similar areas of the language, and might work well together, but I think that we can also consider them separately (as well as together). In particular I consider that named parameters let you achieve something that is hard to do otherwise (readable lists of mandatory parameters), whereas default parameters can be achieved with overloaded methods (delegating to a 'master' method).

1) Given: foo("bar");, which of the two parameters is supposed to be "bar" and which is supposed to be "foo" if the method sig is:

public void foo(String a = "foo", String b = "bar") {}? That problem does not arise with named params.

If C++-style default parameters are used, then only default parameters at the end of the parameter list can be used. In this example, a would be set to "bar" and b would default to "bar". Or with one of your examples from an earlier thread:

public named void foo(String arg1, int arg2 = 5, String arg3 = "foo") {}

Then the following call would be an error: foo(arg1: "a", arg3: "b");

Only the following calls would be allowed: foo(arg1: "a", arg2: 2, arg3: "b"); foo(arg1: "a", arg2: 2); foo(arg1: "a");

This would simplify method selection, and I suppose would be the only way to do so without named parameters.

Requiring the use of named parameters could let you use defaults in the middle of the parameter list, but then you are left with restrictions on how they can be overloaded and overridden (which might be more problematic).

If I'm undervaluing the benefits of named parameters, by all means, fill out a proposal yourself and/or edit the one I'll be writing up. Contact me so we can work together.

I think that my named parameters proposal (in an earlier thread) still largely holds, though it doesn't consider default values, and the use of annotations seems to be contentious (and is certainly not the only solution), but I think that it potentially requires the fewest changes to the language. However, I think that named parameters with default values and also just default parameter values would also be valid and useful proposals, and probably provide more functionality at the cost of greater change required. In addition, the simpler constructor syntax mentioned by Howard Lovatt could also be useful (but maybe out of scope of Project Coin). There also seem to be a range of ways to implement named parameters which really be applied to each solution (annotations, keywords, and named parameters by default).

Therefore, do you know what the real goal of the proposals presented in this group should be? Is it to just identify the possibilities and discover their advantages and disadvantages, or is some consensus also required? Should just one (potentially combined) proposal be produced for named parameters, or should separate proposals be produced for each variation? Does the compiler group have any suggestions (Joe Darcy)? I'm certainly happy to help in any way (and am enjoying these constructive discussions).

Paul

More information about the coin-dev mailing list