const parameters

[Pansje]

Hi,

I wonder why Java doesn't support const parameters. In C++ I use it whenever
possible. Any ideas?

Hans

 

[Roedy Green]

I wonder why Java doesn't support const parameters. In C++ I use it whenever
possible. Any ideas?

Use immutable objects.
Use final locals

see http://mindprod.com/jgloss/immutable.html

 

[Tor Iver Wilhelmsen]

I wonder why Java doesn't support const parameters. In C++ I use it whenever
possible. Any ideas?

You mean apart from being a different language? The world would be a
much better place if people didn't come to a language carrying a bunch
of assumptions from their previous one.

 

[Liz]

You mean apart from being a different language? The world would be a
much better place if people didn't come to a language carrying a bunch
of assumptions from their previous one.

One of my programs has this line, is it the same?

public void spawn(final Component parentFrame) {...

 

[Peter Ashford]

One of my programs has this line, is it the same?

public void spawn(final Component parentFrame) {...

Wow! You learn something new every day - that seems to do the job -
eclipse helpfully tells me that you cannot assign to a final parameter:

void test(final int i){

i = 20; // THIS IS ILLEGAL


That's cool, I never knew that was in java.

 

[David Hilsee]

One of my programs has this line, is it the same?

public void spawn(final Component parentFrame) {...

Not quite. Java's final and C++'s const are somewhat similar, but
different. In C++, the programer can label methods (known as "member
functions" in C++) as const, which means "this function does not modify the
object." Java does not support this. The above code snippet merely makes
changing the value of the parentFrame reference impossible. It does not
make modifying the object impossible (via a setter, for example). In C++,
given a class that labels each method const and non-const, it is possible to
prevent accidental modification of the object passed.

 

[Tor Iver Wilhelmsen]

Not quite. Java's final and C++'s const are somewhat similar, but
different. In C++, the programer can label methods (known as "member
functions" in C++) as const, which means "this function does not modify the
object." Java does not support this.

In short: Java's final modifier supports only the second const here:

const method(const * const Object object)

For primitives, which you don't have pointers to, it only supports
constness of the value, e.g. the second const in

const method(const int i)

 

[Liz]

Not quite. Java's final and C++'s const are somewhat similar, but
different. In C++, the programer can label methods (known as "member
functions" in C++) as const, which means "this function does not modify the
object." Java does not support this. The above code snippet merely makes
changing the value of the parentFrame reference impossible. It does not
make modifying the object impossible (via a setter, for example). In C++,
given a class that labels each method const and non-const, it is possible to
prevent accidental modification of the object passed.

Did you test this for references (primitives were tested
by peter and you can't change them), there seems to be no value
to changing the reference on the stack so final must do
something usefull don't you think?

 

[Liz]

-----------
Here is my test. Pass a reference to an Integer object. Compiler generates
error message for this prog as follows:

test.java:10: final parameter i may not be assigned
i = new Integer(4);
^
1 error

1 class test {
2 final static Integer i = new Integer(8);
3 public static void main(String args[]) {
4 System.out.println(i);
5 jones(i);
6 System.out.println(i);
7 System.exit(0);
8 }
9 static void jones(final Integer i){
10 i = new Integer(4);
11 return;
12 }
13 }

So you can't modify the object it seems.

 

[Tor Iver Wilhelmsen]

So you can't modify the object it seems.

Your particular case uses an "immutable" object (Integer), and only
tries to change the final reference. To see that final doesn't prevent
you prom chaning an object's _state_, try this:

class test {
final static StringBuffer b = new StringBuffer("Test");
public static void main(String args[]) {
System.out.println(b);
jones(b);
System.out.println(b);
System.exit(0);
}
static void jones(final StringBuffer b){
// Change object state
b.append(" works");
return;
}
}

 

[Chris Uppal]

You mean apart from being a different language? The world would be a
much better place if people didn't come to a language carrying a bunch
of assumptions from their previous one.

Seems a bit harsh -- the OP was not criticising Java for not resembling C++, he
was asking why a feature of C++ was deemed unsuitable for Java.

After all, Java was very clearly derived in part from C++, so there is a
definite sense in which any C++ feature that is not in Java must have been
deliberately left out.

A similar question could be asked about why Java doesn't have header files.
The answer would talk about the bytecode /classfile architecture, about
different ways of separating interface from implementation, about dependency
management, etc, etc.

Asking /why/ something is different is not asserting that it should /not/ be
different.

In this instance, I think that mutability control was left out of the Java type
system because the Java designers felt that it added more complexity than it
was worth. (I also think that they were wrong in this, as in so many things,
but that's another story).

-- chris

 

[Doug Pardee]

Seems a bit harsh -- the OP was not criticising Java for not resembling
C++, he was asking why a feature of C++ was deemed unsuitable for Java. [snip]
Asking /why/ something is different is not asserting that it should /not/ be
different.

Taken out of context, I would agree. If the poster had been asking
James Gosling why, it would be completely reasonable. But the poster
was addressing this Usenet newsgroup. Other than Neal Gafter, I don't
think there's anyone here who has any kind of definitive knowledge
about why *any* language choices were made. In context, the use of
"why" by the original poster does not really ask a question, it
indicates annoyance.

If the OP really wants to know why const was omitted from Java, he'll
have to ask Gosling. Or maybe do a Web search, which quickly turned up
this from Joshua Bloch:
"We do not have plans to add support for the const keyword to the
Java language. It was a mixed blessing in C++; as you know, it's
merely advisory, and can cast on or off. Gosling hated it, and did
final instead. What you really want is 'immutable,' but it's a
research problem to make this work properly."
(http://java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html)

So that looks like the fundamental answer: Gosling hated const.

 

[Pansje]

Taken out of context, I would agree. If the poster had been asking
James Gosling why, it would be completely reasonable. But the poster
was addressing this Usenet newsgroup. Other than Neal Gafter, I don't
think there's anyone here who has any kind of definitive knowledge
about why *any* language choices were made. In context, the use of
"why" by the original poster does not really ask a question, it
indicates annoyance.

My original question was:
"I wonder why Java doesn't support const parameters. In C++ I use it
whenever
possible. Any ideas?"

I didn't ask for "definitive knowledge", but for "any ideas"
I just thought that perhaps someone in this group might know more than I
do.
( and I still think so, because my knowledge is quite limited )

Neither is it an attack or criticism to Java, nor a suggestion that Java
should have all C++ "features".

If the OP really wants to know why const was omitted from Java, he'll
have to ask Gosling.

Sorry, never heard of him, so couldn't ask him.

Or maybe do a Web search

Indeed, I do that often, but this time I didn't

which quickly turned up this from Joshua Bloch:

Well, quickly..? I'm still on a dial up connection. Just visiting a few web
pages, with all the moving images and flash animations, takes quite a while.

"We do not have plans to add support for the const keyword to the
Java language. It was a mixed blessing in C++; as you know, it's
merely advisory, and can cast on or off. Gosling hated it, and did
final instead. What you really want is 'immutable,' but it's a
research problem to make this work properly."
(http://java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html)

So that looks like the fundamental answer: Gosling hated const.

So I got an answer after all,
thanks

Hans

 

[Roedy Green]

I found that in practice few C/C++ programmers understood const. The
would just yank it off when it got in the way. Java's scheme is a
little easier to understand, and hopefully won't be treated as
casually.

 

[Roedy Green]

"I wonder why Java doesn't support const parameters. In C++ I use it
whenever
possible. Any ideas?"

I didn't ask for "definitive knowledge", but for "any ideas"

see http://mindprod.com/jgloss/newsgroups.html#GIFTHORSE

You are under the delusion that newsgroups exist for your convenience,
that they are sort of like a heavenly help desk with dozens of people
eager to serve you.

A better analogy would be, that you are permitted to toss ideas into
the ring for others to discuss to allow them to share their knowledge
with each other, and to entertain each other. As a special privilege,
you are allowed to watch and even participate.

The performance is NOT entirely for your benefit. You really get
people's backs up when you suggest it is a command performance solely
to please your Royal Highness.

 

[Liz]

Your particular case uses an "immutable" object (Integer), and only
tries to change the final reference. To see that final doesn't prevent
you prom chaning an object's _state_, try this:

I did not realize that Interger was immutable, thanks for the clarification.
Your test program demonstrates this very well.

class test {
final static StringBuffer b = new StringBuffer("Test");
public static void main(String args[]) {
System.out.println(b);
jones(b);
System.out.println(b);
System.exit(0);
}
static void jones(final StringBuffer b){
// Change object state
b.append(" works");
return;
}
}

 

[Liz]

Seems a bit harsh -- the OP was not criticising Java for not resembling C++, he
was asking why a feature of C++ was deemed unsuitable for Java.

You mean like asking why Pitsburg doesn't have the nice beaches that Hawaii
does?

 

[Dale King]

Did you test this for references (primitives were tested
by peter and you can't change them), there seems to be no value
to changing the reference on the stack so final must do
something usefull don't you think?

The thing they do usefull and the only reason they exist (realize that they
did not exist until Java 1.1) is to allow local nested classes (classes
declared within a method) to access the value that a variable had when the
class instance is created.

So you can do something like this:

Runnable getCounter( final int count )
{
return new Runnable()
{
public void run( )
{
for( int i = 0; i < count; i++ )
{
System.out.println( i );
}
}
}
}

That is the reason why local variables (which includes parameters) are
allowed to be declared final.