Why default parameter values where not included in Java

[axer]

I'm looking for any links or documentation that describes why default
parameter values where not included in Java.

I'm not looking for opinion on the matter, or for speculation.

I'm only interested in information that DIRECTLY describes the issue,
and listed in a reputable site or book.

Thank you

 

[Rhino]

I'm looking for any links or documentation that describes why default
parameter values where not included in Java.

I'm not looking for opinion on the matter, or for speculation.

I'm only interested in information that DIRECTLY describes the issue,
and listed in a reputable site or book.

I've been coding Java for several years and I don't know what you're talking
about.

What default parameters are you looking for? Java and the JVMs seem to have
lots of defaults in them; for example, if you don't specify a memory
parameter, a default amount of memory is assumed.

I'm not sure what you're hoping to find either; it's not that often that a
company will write documentation about why they DIDN'T do something.
Documentation usually covers things that were done, not omitted.

I suppose you *might* find something like interviews with top designers at
Sun explaining why they took a certain path and chose not to take some other
path that could touch on whatever you're after. Sun has some chat
transcripts at java.sun.com so if you look through those you might find what
you want.

But without knowing more clearly what you want, I can't suggest more than
that.

Rhino

 

[Adam Maass]

I've been coding Java for several years and I don't know what you're
talking
about.

What default parameters are you looking for? Java and the JVMs seem to
have
lots of defaults in them; for example, if you don't specify a memory
parameter, a default amount of memory is assumed.

I believe the OP means the C++ feature that looks like this:

void myMethod(int aParameter = 3) {
// do something useful with aParameter
}

Now, you can call myMethod with:

myMethod()


and the parameter 'aParameter' gets set to the value '3'.


But you can also call myMethod with:

myMethod(7)

and the parameter 'aParameter' is set to the value '7'.



I know the OP asked us not to speculate, but this one is so blindingly easy
that it's obvious.

In Java, you simply write overloaded methods:

void myMethod() {
myMethod(3);
}

void myMethod(int aParameter) {
// do something useful with aParameter
}


It cuts down on the amount of syntax, and Java was meant to be a simpler
language than C++.


By the way, you could also write the overloaded methods in C++, but there
are subtle differences between default parameters and overloaded methods --
that I don't quite grok, as I've never been a particularly proficient C++
programmer.

-- Adam Maass

 

[axer]

** Please, no debates, or speculations. We'll just waste your time and
my time. **

This is exactly why I asked for no speculation, because every Java
programmer I've asked this question always gives me incorrect logic.
As I'm sure you're aware of, your method is called overloading.
And the overloading method takes much more syntax then does using
default parameters. See example below:

I'm not interested in debating this issue, or speculation, because I
don't expect most Java programmers to fully understand the advantages
of default parameter arguments, nor how easy it is to implement into a
language.

That's why I'm only interested in any links or references to reputable
sites or book(s) that will DIRECTLY state the Java designers reason for
not including default parameter arguments in Java.

** Please, no debates, or speculations. We'll just waste your time and
my time. **


//The C/C++ way using defautl parameters
int ShowMessage(string MainMsg, string Title = "Info", int MessageType
= FooWarning, int MessageButtons = IDOK)
{
//Do message
}

The above is much easier to understand, easier to maintain, and easier
to find what you're looking for then the following Java overloaded
method:

int ShowMessage(string MainMsg, string Title, int MessageType, int
MessageButtons)
{
//Do message
}

int ShowMessage(string MainMsg, string Title, int MessageType)
{
return ShowMessage(MainMsg, Title, MessageType, IDOK);
}

int ShowMessage(string MainMsg, string Title)
{
return ShowMessage(MainMsg, Title, FooWarning, IDOK);
}

int ShowMessage(string MainMsg)
{
return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
}

 

[Antti S. Brax]

** Please, no debates, or speculations. We'll just waste your time and
my time. **

Sorry, but Usenet does not work like that.

You throw us a question and we discuss it. If our discussion
answers your question or is helpful in some other way, that
is just a coincidence.

This is exactly why I asked for no speculation, because every Java
programmer I've asked this question always gives me incorrect logic.
As I'm sure you're aware of, your method is called overloading.

So, how exactly do you spot the incorrect logic? Is it because
you already know the answer and are just trolling the group?
Is it because you have formed an opinion and the explanations
don't fit it? Maybe you should think about not being such an
harc core language fanatic?

I'm not interested in debating this issue, or speculation, because I
don't expect most Java programmers to fully understand the advantages
of default parameter arguments, nor how easy it is to implement into a
language.

Yeah, you're just trolling. And you're not even good at it.

 

[Thomas Schodt]

I believe the OP means the C++ feature that looks like this:

void myMethod(int aParameter = 3) {
// do something useful with aParameter
}

** Please, no debates, or speculations. We'll just waste your time
and my time. **

You do realise you are the one wasting other peoples time
by not making it clear what you are asking about.

Adam Maass made a guess.

You did not even bother quoting him and saying if that is what you mean.

Instead you harp on about how you think Usenet ought to work.

That's why I'm only interested in any links or references to reputable
sites or book(s) that will DIRECTLY state the Java designers reason
for not including default parameter arguments in Java.

The Java designers did not consider the C++ style method default
argument feature worthwhile.

A better question would be
why did Stroustrup consider it worthwhile putting into C++?

Others have pondered over the severely limited virtues
of method default parameters features

** Please, no debates, or speculations. We'll just waste your time
and my time. **

You may opt to request of others what you would like them to do.
Others may opt to honour your request if they feel like it.

 

[Adam Maass]

//The C/C++ way using defautl parameters
int ShowMessage(string MainMsg, string Title = "Info", int MessageType
= FooWarning, int MessageButtons = IDOK)
{
//Do message
}

The above is much easier to understand, easier to maintain, and easier
to find what you're looking for then the following Java overloaded
method:

int ShowMessage(string MainMsg, string Title, int MessageType, int
MessageButtons)
{
//Do message
}

int ShowMessage(string MainMsg, string Title, int MessageType)
{
return ShowMessage(MainMsg, Title, MessageType, IDOK);
}

int ShowMessage(string MainMsg, string Title)
{
return ShowMessage(MainMsg, Title, FooWarning, IDOK);
}

int ShowMessage(string MainMsg)
{
return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
}

I don't disagree with you. And the client of the class in question would
have the same interface using either approach.

My reference to "less syntax" does not equate to "less verbose" or even
"more clear." I think the default parameter syntax was left out of Java
because -- from the perspective of a client of the class -- the same effect
can be achieved with method overloading, and method overloading was going to
be incorporated into Java anyway for other reasons, and the syntax for
default parameters in C++ just complicates the parsing rules of the language
for very little perceived benefit. Again, let me emphasize: from the
perspective of a client of the class, not an author or maintainer of the
class.

In addition, the way default parameters are implemented in (most flavors of)
C++ would be difficult to achieve in Java given its dynamic class loading
scheme. So even if default parameters had been carried over into Java from
C++, it is likely that the language spec would have required Java compilers
to treat any default parameter syntax as a shorthand for method overloading.

-- Adam Maass

 

[axer]

I don't disagree with you. And the client of the class in question
would
You're the first Java developer to come up with a reason that sounds
remotely possible and/or logical.

overloading.

What would be wrong with the Java compiler converting it to overloaded
methods?
I don't see what problems this would cause.
For example
http://java.sun.com/j2se/1.3/docs/api/javax/swing/JOptionPane.html
In the above link, if you look at the showMessageDialog method,
you'll see there are four overloaded methods.
Some or all of these methods could have been combined into one method
with default values.

If the compiler converted the following function into four separate
methods, how would that cause a problem?

int ShowMessage(string MainMsg, string Title = "Info", int MessageType
= FooWarning, int MessageButtons = IDOK);

Since it seems that no one really knows the official reason for this
feature not being included in the language, I guess I'll venture down
the debate road.
To be perfectly honest, my opinion is firm as to whether default
arguments are good for a language in GENERAL.

What I'm not sure of is whether default arguments are good for Java
specifically.

So what is unique about Java that would make it incompatible with
default parameter values, compare to other languages like C/C++?

 

[alan]

You're the first Java developer to come up with a reason that sounds
remotely possible and/or logical.

You are a goob.

Since it seems that no one really knows the official reason for this
feature not being included in the language, I guess I'll venture down
the debate road.

How dare you waste my time! Do this! Do that!

 

[Chris Uppal]

That's why I'm only interested in any links or references to reputable
sites or book(s) that will DIRECTLY state the Java designers reason for
not including default parameter arguments in Java.

There are a number of people hereabouts who are certainly as "reputable"
sources of information and insight as whatever sites or book(s) you are likely
to find. But your tone is not such as to encourage them to respond helpfully.

FWIW, I believe that default arguments are simply incompatible with Java
semantics. Its a matter of the differences between the name resolution schemes
in C++ and Java, but I'll leave you to look up the details yourself.

-- chris

 

[axer]

There are a number of people hereabouts who are certainly as
"reputable"
I'm certain there are. But I can not use them as a reference.
yourself.

Specifically what name resolution differences?

 

[Roland]

I don't disagree with you. And the client of the class in question would
have the same interface using either approach.

My reference to "less syntax" does not equate to "less verbose" or even
"more clear." I think the default parameter syntax was left out of Java
because -- from the perspective of a client of the class -- the same effect
can be achieved with method overloading, and method overloading was going to
be incorporated into Java anyway for other reasons, and the syntax for
default parameters in C++ just complicates the parsing rules of the language
for very little perceived benefit. Again, let me emphasize: from the
perspective of a client of the class, not an author or maintainer of the
class.

In addition, the way default parameters are implemented in (most flavors of)
C++ would be difficult to achieve in Java given its dynamic class loading
scheme. So even if default parameters had been carried over into Java from
C++, it is likely that the language spec would have required Java compilers
to treat any default parameter syntax as a shorthand for method overloading.

-- Adam Maass

Adam, your reasoning matches strikingly well with the Java design goals
written down by James Gosling and Henry McGilton in the "The Java
Language Environment" whitepaper (1996).

A quote from Chapter 2 "Java -- Simple and Familiar", section 2
[emphasis added]:
<quote>
The first step was to eliminate redundancy from C and C++. In many ways,
the C language evolved into a collection of overlapping features,
providing too *many ways to say the same thing*, while in many cases not
providing needed features. C++, in an attempt to add "classes in C",
merely added more redundancy while retaining many of the inherent
problems of C.
</quote>

I could not find any direct reference to default parameter values in the
whitepaper. IOW and as I interpret it: default parameter values have
been not been included in Java, because it can be equally expressed by
other means (method overloading).

The whitepaper can be found at Sun's Java site:
<http://java.sun.com/docs/white/langenv/>.

It's fun to read why the didn't include enums (section 2.2.3). While
other sections have a title starting with "No *more* ...", section 2.2.3
is called "No Enums". Somehow I get the feeling they already consider
enums for a future version (and now, as we all know, enums have made it
in Java 5).
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[axer]

//The C/C++ way using defautl parameters
int ShowMessage(string MainMsg, string Title = "Info", int MessageType
= FooWarning, int MessageButtons = IDOK)
{
//Do message
}

The above is much easier to understand, easier to maintain, and easier
to find what you're looking for then the following Java overloaded
method:

int ShowMessage(string MainMsg, string Title, int MessageType, int
MessageButtons)
{
//Do message
}

int ShowMessage(string MainMsg, string Title, int MessageType)
{
return ShowMessage(MainMsg, Title, MessageType, IDOK);
}

int ShowMessage(string MainMsg, string Title)
{
return ShowMessage(MainMsg, Title, FooWarning, IDOK);
}

int ShowMessage(string MainMsg)
{
return ShowMessage(MainMsg, "Info", FooWarning, IDOK);
}

I don't disagree with you. And the client of the class in question would
have the same interface using either approach.

My reference to "less syntax" does not equate to "less verbose" or even
"more clear." I think the default parameter syntax was left out of Java
because -- from the perspective of a client of the class -- the same effect
can be achieved with method overloading, and method overloading was going to
be incorporated into Java anyway for other reasons, and the syntax for
default parameters in C++ just complicates the parsing rules of the language
for very little perceived benefit. Again, let me emphasize: from the
perspective of a client of the class, not an author or maintainer of the

class.

In addition, the way default parameters are implemented in (most flavors of)
C++ would be difficult to achieve in Java given its dynamic class loading
scheme. So even if default parameters had been carried over into Java from
C++, it is likely that the language spec would have required Java compilers
to treat any default parameter syntax as a shorthand for method overloading.

Adam, your reasoning matches strikingly well with the Java design goals
written down by James Gosling and Henry McGilton in the "The Java
Language Environment" whitepaper (1996).
A quote from Chapter 2 "Java -- Simple and Familiar", section 2
[emphasis added]:
<quote>
The first step was to eliminate redundancy from C and C++. In many ways,
the C language evolved into a collection of overlapping features,
providing too *many ways to say the same thing*, while in many cases not
providing needed features. C++, in an attempt to add "classes in C",
merely added more redundancy while retaining many of the inherent
problems of C.
</quote>
I could not find any direct reference to default parameter values in the
whitepaper. IOW and as I interpret it: default parameter values have
been not been included in Java, because it can be equally expressed by
other means (method overloading).

The same could be said for enums. As the link you posted shows:
http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627

By the way, thanks for the link. I've been looking for a good list
showing the difference between C++ and Java, and your link seems to
cover it pretty good.

 

[Roland]

Adam, your reasoning matches strikingly well with the Java design

goals

written down by James Gosling and Henry McGilton in the "The Java
Language Environment" whitepaper (1996).
A quote from Chapter 2 "Java -- Simple and Familiar", section 2
[emphasis added]:
<quote>
The first step was to eliminate redundancy from C and C++. In many

ways,

the C language evolved into a collection of overlapping features,
providing too *many ways to say the same thing*, while in many cases

not

providing needed features. C++, in an attempt to add "classes in C",
merely added more redundancy while retaining many of the inherent
problems of C.
</quote>
I could not find any direct reference to default parameter values in

the

whitepaper. IOW and as I interpret it: default parameter values have
been not been included in Java, because it can be equally expressed

by

other means (method overloading).

The same could be said for enums. As the link you posted shows:
http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627

I'm not sure what it is you are wanting to say here. Gosling c.s. *did
not* add enums to the Java language, *because* (at the time) they
thought it could equally be expressed other means, i.e. "by declaring a
class whose only raison d'etre is to hold constants" [quoted from the
link above].
--
Regards,

Roland de Ruiter
___ ___
/__/ w_/ /__/
/ \ /_/ / \

 

[Chris Smith]

If the compiler converted the following function into four separate
methods, how would that cause a problem?

It wouldn't, by itself, cause a problem. Very few such features, in and
of themselves, cause any problem. If you create a language with a bunch
of them, though, then you get C++. Java was designed to *not* be
something like C++ for a number of reasons:

1. Sun believed that serious software could be developed using a
language with a simpler and easier to understand language definition,
and that the result could lead to higher quality of software.

2. Sun wanted to encourage fast adoption of Java by a very large group
of developers, and was not willing to bet on anyone spending the time
needed to become familiar with another C++.

3. Java needed to be safely portable across implementations of compilers
and virtual machines, and adding more complexities to the language makes
that harder to achieve, and to test that it has been achieved.

4. Java achieved an aesthetic sense of being a small and simple
language, and adding more features would interfere with that goal.

The issue is not whether the feature could save a few lines of code.
People who believe that an extra language feature is justified because
it saves them five lines of code do *not* program in Java. The issue is
also not whether the feature is easy to implement; obviously, it is.
The issue is what effect the feature has on the central concepts and
design of the Java programming language. Clearly, it is opposed to the
concepts behind Java 1.0, and it's inclusion would have been
discongruous at best.

It is far less clear that default parameters would be at all out of
place in Java 1.5, which has backed off of Java 1.0's direction to a
large extent (e.g., variable argument lists, enums, autoboxing, static
import, and so on); and it remains to be seen whether default parameters
will eventually be added as well.

Since it seems that no one really knows the official reason for this
feature not being included in the language, I guess I'll venture down
the debate road.

The problem is deeper than that no one knows. There is no "official"
reason. Sun doesn't publish opinions a la U.S. Supreme Court justices.
They make and release products, and the reasons of various team members
may have different reasons for making the same decision. You could look
for comments by James Gosling, who led the team and probably wrote much
of the code, but that's still not an "official" reason.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

You're the first Java developer to come up with a reason that sounds
remotely possible and/or logical.

Whatever. I just wrote a long response before I saw this. Now I
realize you're just trolling. Thanks for wasting my time.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tor Iver Wilhelmsen]

The same could be said for enums. As the link you posted shows:
http://java.sun.com/docs/white/langenv/Simple.doc2.html#5627

If you want an implementation of default parameters in Java, submit a
request to the JCP. One possible implementation could be that the
compiler generated the necessary overloaded methods, e.g. turned

public void foo(String fie = "dummy") { }

into the class-file versions of both

public void foo(String fie) {
}

and

public void foo() { foo("dummy); }

The problem comes in the case of two neighbour arguments of the same
type: Which of the two should a "reduced" argument list use? i.e.

public void foo(int x = 0, int y = 42) { }

should result in

public void foo(int x) { foo(x, 42); }

or

public void foo(int y) { foo(0, y); }

? Your proposal need to cover that case, e.g. by stating a rule that
the first argument will be "exposed" to the programmer.

 

[Joona I Palaste]

The problem comes in the case of two neighbour arguments of the same
type: Which of the two should a "reduced" argument list use? i.e.

public void foo(int x = 0, int y = 42) { }

should result in

public void foo(int x) { foo(x, 42); }

public void foo(int y) { foo(0, y); }

? Your proposal need to cover that case, e.g. by stating a rule that
the first argument will be "exposed" to the programmer.

AFAIK C++ uses the same rule.