Javalobby - Comments for "Borrowing Language Features - Default Argument Values in Java"

But it would impact

okidoky — Sat, 29 Mar 2008 12:09:59 -0400

But it would impact performance when passing primitives.

The idea for optional

stefan.schulz — Sat, 29 Mar 2008 05:38:48 -0400

The idea for optional parameters is not new and has been discussed in many variations. The comments I've read mix up two things (that maybe related though): optional parameters and readability (e.g. named parameters).

Current Java already has "optional" parameters in form of Varargs. The naive approach (no language change) would be to pass optional parameters within that Vararg and unpack them at method side. This would of course cause a lot of boiler plate and it's not type safe.

One could make the compiler handle that boilerplate and interpret defaulted parameters as part of a Varargs parameter. The compiler would wrap arguments into the Vararg array at invocation time (including autoboxing primitives to allow for null) and unwrap those arguments having a corresponding parameter within the invoked method. This would overcome some of the issues mentioned wrt. signature changes and be compatible to current Java at bytecode level.

I ran into the following

okidoky — Fri, 28 Mar 2008 14:36:53 -0400

I ran into the following problem before when I was trying to argue for named arguments. eg:

<code>
int method(int x = 0, int y = 0, int w = 320, int h=240)
...
method(w: 640, h: 480);
</code>

In addition to the default arguments, it makes it very clear what parameters you're trying to pass in.

Great alternative to calls like this: something(0, null, null, null, 0, "something", "something else").
What the heck is what?

But, one of the problems was that where should the code go where the default is set? The method or the calling method? If it goes in the calling method, then the default value needs to described in the class file. It could be annotation that an updated javac compiler would automatically create for you I suppose.

But what if that third party library changes and the default parameter changes. Or what if the default parameter is removed and is not optional anymore? Now you have code that still runs, but can't be recompiled.

There were some other arguments against it, one in particular, just can't remember what...

Personally I prefer using

hb14717 — Fri, 28 Mar 2008 13:09:24 -0400

Personally I prefer using overloading to fake the default argument property simply because it requires less work from the caller whereas the null checking solution requires the same amount of work from the caller to call the method:

methodA(null,null,null);

and in my opinion, passing null values to methods makes it harder to understand the code. I agree that it need not be an all or nothing approach - It could simply be that default values are allowed for anything that can be defined as a literal (as in the restriction that a vararg must be the last parameter). However, I also don't see why you could not specify default values by calling a constructor explicitly:

void methodA(Date date = new Date()) {}

void methodB(Person p = new Person("John", "Doe")) {}

Maybe we don't need the

mgrev — Fri, 28 Mar 2008 12:46:48 -0400

Maybe we don't need the ultimate flexibility on this one. Maybe only immutable objects, like for default values in annotations, and/or require a final method declararion.

Cheers
Mikael

I agree about borrowing

knasser — Fri, 28 Mar 2008 11:52:00 -0400

I agree about borrowing useful features from other languages, but not this one :)

default arguments are handy when it comes to primitives which are passed by value, and also to immutable objects like String in your example.

but how do you want it to work for normal mutable objects?

should a new object be created automatically? if yes , which constructor to use

so I think default arguments is really asking for troubles

The alternative is to do something like this, it might not be very readible but at least you have control:

public void methodA(String arg1, String arg2, String arg3) {  
arg3=  arg3 != null ? arg3 : "default";    
}

The overloading is also okay but in case you need default values for multiple arguments you will end up creating having many methods with all possible combination of default arguments, for the example you use imagine you want to have a default value for the 3 arguments. you will end up with this

public void methodA(A arg1) { }
public void methodA( B arg2,) { }
public void methodA(C arg3) { }
public void methodA(A arg1, B arg2) { }
public void methodA(A arg1, C arg3) { }
public void methodA( B arg2, C arg3) { }
public void methodA(A arg1, B arg2, C arg3) { }

imagine with four arguments!

this is probably easier although not very sexy

public void methodA(A arg1, B arg2, C arg3) {  

arg1=  arg1 != null ? arg1 : new A();
arg2=  arg2 != null ? arg2 :  new B();
arg3=  arg3 != null ? arg3 : "new C();


}

Microsoft docs: Use method

mt79448 — Fri, 28 Mar 2008 11:11:19 -0400

Microsoft docs:

Use method overloading instead of allowing default arguments. Default arguments do not version well and therefore are not allowed in the Common Language Specification (CLS).

From here: http://msdn2.microsoft.com/en-us/library/xxfyae0c(VS.71).aspx

I seem to remember some programming puzzlers from people who combined method overloading and default arguments in C++.

There is one quite important

abies — Fri, 28 Mar 2008 10:31:32 -0400

There is one quite important difference between java and other languages as far as default arguments are concerned. In all the other cases (I know about), default arguments are resolved on compile time (so it is just compiler trickery, which inserts missing arguments behind the scenes). To follow 'java way' default arguments in java would have to work differently - you would be really calling function with some arguments missing and they would be filled out at call/link time.

Why it makes a difference? Think about 3rd party library, exporting function doSomething(String name). In next release, they want to add doSomething(String name, boolean ignoreCase = false). Currently, they will just export two methods (one for backward compatibility). With java style defaults, they can just change the function by adding a parameter with default value and all existing program will continue to work.

Unfortunately, to get a full power of that, we need named arguments - and named arguments are not so easy to get inside 'mature' language. I would prefer to rather wait some more time for named arguments, rather than having C++ style, compile-time only defaults soon.

My thoughts on this topic is

hb14717 — Fri, 28 Mar 2008 09:32:39 -0400

My thoughts on this topic is exactly like yours. The java developers I've discussed this with tend to agree with that view or tend not to mind it either way. I'm hoping there's some good responses that indicate why such a feature should not be allowed.

Yes!! I really want this

mgrev — Fri, 28 Mar 2008 09:30:30 -0400

Yes!! I really want this as well. It would clean up a lot of APIs, new ones at least. A no-brainer to me.

I would rather have this

bloid — Fri, 28 Mar 2008 07:36:42 -0400

I would rather have this than almost every other "new feature" suggested so far... It's the one thing I *still* miss from my Delphi days (and that was almost 10 years ago)