JDK-4093718 : const - qualifier for methods, parameters and return-value
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.1.4,1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,windows_95
  • CPU: generic,x86
  • Submitted: 1997-11-18
  • Updated: 1997-12-04
  • Resolved: 1997-12-04
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
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
23-09-2002
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
18-11-1997