On 03/20/09 23:04, Frank Schönheit - Sun Microsystems Germany wrote:
In all other cases, it is at the implementations discretion whether for
a given KeyType, it is possible to put the VOID key into the map.
Strictly, you could say it should not be possible since actually, VOID
is not a value from KeyType's value set. It is "only" that the generic
API ("put( any, any)") allows for VOID keys, where a less generic API
("XMap< KeyType, ValueType > { put( KeyType, ValueType ); }" ) would not
allow for it.
However, I would not restrict implementations too much, so I preferred
to leave it undecided in the interface definition whether VOID keys (or
values) are accepted.
Why special case VOID and not, say, CHAR?
But I get your point:
Leave out "unreasonable" types that would lead to hassle in the
implementations (one might also want to leave out float and double,
given their peculiarities).
I am not sure I should dare to ask ... with peculiarities of float and
double, you refer to what? The only thing I can imagine right now is
their ... imprecision, which shouldn't be a problem in this context. Do
they have more issues, perhaps when passed around crossing bridges?
Yes, equality over floating point numbers is complicated by precision
(e.g., in languages like C and C++, intermediates may arbitrarily be
kept in extended-precision registers, so that x+y==x+y need not be true)
and NaN (where NaN==NaN is false).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
