Proposal [UPDATED]: Make sure C++ getters are const and C getters take a const object pointer

UPDATE:
The following API are virtual functions on DecimalFormat:

 getRoundingMode
 getRoundingIncrement
 getFormatWidth
 getPadPosition
 getPadCharacterString
 getMinimumExponentDigits

Making these API const is a non-breaking change for *calling* code.

However, making these API const is a *breaking* change for *subclasses of 
DecimalFormat that override these functions.*  If anyone will be 
incovenienced by this change, because they have such subclasses, please 
respond to this list.

Expires: April 7, 2004

__________________


Affects: ICU4C 3.0

Background:  The following C++ methods on DecimalFormat are all marked
@stable ICU 2.0.  These methods are all getters, that is, they retrieve
data from an object without changing the object.

getRoundingMode
getRoundingIncrement
getFormatWidth
getPadPosition
getPadCharacterString
getMinimumExponentDigits

Problem:  These are non-const methods.  As such, they cannot be called on
const objects.  Example:
const DecimalFormat& fmt;
int32_t width = fmt.getFormatWidth(); // compiler error!
The methods should be const.

Proposal:  I would like to change the signature of these methods by
marking them const.

For example, this API:
/**
* Get the width to which the output of format() is padded.
* @stable ICU 2.0
*/
virtual int32_t getFormatWidth(void);

would change to:
/**
* Get the width to which the output of format() is padded.
* @stable ICU 2.0
*/
virtual int32_t getFormatWidth(void) const;

I realize this violates the *letter* of the ICU API migration policy--but
not the spirit, in my opinion.  I think this is desirable because:
- The change will not break any client code.  Going from const to
non-const is a breaking change, but non-const to const is okay.  A
recompile is required, but nothing else.
- The change will fix the API by making it possible to call getters on
const objects (as was intended).

I think this is strongly preferable to adding a parallel set of const
methods that do the same thing, and deprecating the existing methods.  I
don't see any benefit to doing that.

I would like to retain the label of @stable ICU 2.0.  We could mark these
@draft ICU 3.0 but I don't think it's necessary.

If people agree to this, I'd like to further propose that if we find other
C++ getters that are accidentally declared non-const, we fix them in the
same non-breaking way.

The same issue applies to C API; getter functions should take a const
pointer as their initial parameter, e.g., unum_getAttribute(const
UNumberFormat* fmt, ...), *not* unum_getAttribute(UNumberFormat* fmt,
...).  These can be fixed in a similar non-breaking way if any are found.

>> In other words, please consider this to be a general proposal, not
necessarily limited to DecimalFormat. <<

Please reply with feedback to this list by March 31, 2004.

[Alan S Liu/San Jose/IBM@IBMUS; [email protected];; IBM Globalization;
5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155]
_______________________________________________
icu mailing list
[email protected]
http://oss.software.ibm.com/developerworks/oss/mailman/listinfo/icu