Glen Ezkovich wrote:
>You should do your best not to depend on the values of constants. In fact
>you should do your best not use primitive or String literals for public
>constants.
Sometimes primitive types are unavoidable. If the values are used as array
indexes or case labels, you have no choice but to use primitive integer
types.
Since months of any calendar can be numbered, well, they ARE numbered. See
the API for Calendar.get(MONTH) and set(MONTH,n). It would be impossible
to use a reference type for MONTH and a primitive type for other Calendar
fields.
>>Not true. Constants (defined as compile-time static final literals) MUST
>>remain the same over time, or code breaks because binary compatibility is
>>lost.
>
>You are of course, right. You have to assume this in order to use literal
>constants at all. Unfortunately, I've been burned before.
If you've been burned, it's because binary compatibility was broken.
There's another latent issue there, which is how to design classes that
co-evolve in certain ways. That's a different question than how to design
classes for binary compatibility. Call it source-level compatibility.
>Its an abstract class. It just has an unimaginative view of what types of
>calendars can be dreamed up or it would be *MORE* abstract. ;-)
Yes, and the month-names are misplaced, too. Calendar shouldn't define
them, GregorianCalendar should.
There is no "February" month in the Islamic, Hebrew, or Mayan calendars,
yet they would all derive from Calendar. However, all those calendars do
have a first month, a second month, etc. So they could all work with
numbers, let's say int-typed values, which represent, let's say, the number
of months beyond the first. So 0 would signify the first month, 1 would
signify the second month, and so on. The names are specific to a Calendar,
but the numbers (whatever their significance) are independent of Calendar
type. So: no names, please.
>But the values of the constants are not part of the API.
Implicitly, they are.
The named constants have concrete numeric values, which the compiler is
aware of and uses in specific ways. You can write a switch statement with
Calendar's Gregorian month-names as case labels, and the result might be a
tableswitch with no overt constants in it at all. Yet that tableswitch
would be utterly dependent on the int values and sequence of the
month-names used in the case statements.
Every Java API consists of two things:
1) the source-level API.
2) the binary-level API.
Since Java classes are loaded and linked together dynamically, BOTH are
necessary in order for a program to work.
It's possible to change some things at the source level that have no net
effect for existing source, but which break binary-level compatibility.
The converse is also possible, where binary compatibility is preserved yet
source compability is broken.
Arguably, protected visibility is also part of any public API, if the class
is designed to be extensible by outside developers. Yeah, I've been burned
on that before, too.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
