United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4093718 : const - qualifier for methods, parameters and return-value

Details
Type:
Enhancement
Submit Date:
1997-11-18
Status:
Closed
Updated Date:
1997-12-04
Project Name:
JDK
Resolved Date:
1997-12-04
Component:
tools
OS:
generic,windows_95
Sub-Component:
javac
CPU:
x86,generic
Priority:
P3
Resolution:
Won't Fix
Affected Versions:
1.1.4,1.2.0
Fixed Versions:

Related Reports

Sub Tasks

Description

Name: rm29839			Date: 11/18/97


I'm not one of those people who want everything
from c++ in java...

I think however that java lacks the nicest
feature of c++: const-qualifiers (and I'm not
talking about const-fields - there's the final
keyword for that), but I 'm talking about:

void MyClass :: readMethod(const AType & a, AType & b) CONST
{
}

Some advantages of const-qualifiers:

- programmers can examine the behaviour of a method more easily
- there's less ambiguity in the contract between
  the caller and the callee:
  - A caller doesn't have to worry about whether
    a method will (or will not) change a certain
    parameter. The method specifies in its
    signature whether a certain parameter is
    const or not => no ambiguity
  - When a method returns a private field, it can
    declare its return type to be constant so
    that nobody can modify the private field.

    class Test {
       private MyType field;

        MyType getField()
        {
           return field;
           // not safe!!! - what if some idiot does: new Test().getField().setSomeValue(....)
        }
     }

I know that the contra against const qualifiers
is that it isn't always easy, but isn't it
possible to leave it as an option to the programmer
whether he/she does or does not want to use
const qualifiers?

In case you are not going to do const-qualifiers
in near future, then I would appreciate it very
much if you could tell me the reason for not
doing so. Thanks,

geert mergan   (###@###.###)
last year computerscience
(Review ID: 19924)
======================================================================

                                    

Comments
WORK AROUND



Name: rm29839			Date: 11/18/97



======================================================================

    One way to do this in Java is with subclassing.  If you define a superclass 
that has the read-only methods, then you can declare methods that take only that
superclass, and they won't be able to make any modifications to the instance.
You would still have to construct the fully-functional subclass, and there's
the extra overhead of reading (and writing) the superclass and the subclass.
    Then if you wanted to do what in C++ was

	*(AType*) &constInstance;	/* cast away const-ness */

in Java you would narrow the instance to the subclass that has the modification
methods.  (Of course, you could do the same thing in C++.)

peter.kessler@Eng 1997-11-18
                                     
1997-11-18
EVALUATION

The examples show that the submitter is confused; in the second example such a 
method returns the value of the private field, not a reference to it
that could be used to modify the field externally.  (Such a thing is
possible in C++ but not in Java; in Java, it is only possible to have
a reference to an object, not to an individual field or local variable.
For example, in Java the idiom for passing a reference to a variable as
an argument is to pass a single-element array that is explicitly dereferenced
similarly to the way pointers must be used explicitly in C.)

Note that as of 1.1 (with the inner classes specification) it is possible
to mark method parameters as "final", which is the most frequent use for
const.

david.stoutamire@Eng 1997-12-04


The evaluator above clearly didn't understand the submitter's request.
As other commentors have noted, in Java there are other idioms one can 
use, such as the unmodifiable wrappers in the Collections classes.  
These are sufficient (although certainly not as concise as C++).

###@###.### 2002-09-23
                                     
2002-09-23



Hardware and Software, Engineered to Work Together