On 03/25/09 14:08, Andre Fischer wrote:
Stephan Bergmann wrote:
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?
I would prefer not to have special key at all. The above reasoning
(put(any,any) allows VOID keys) is true for all types supported by ANY
and therefore is not really an argument for having a special key.
I think we start to talk past each other here. I did not want to
discuss demand for a "special key" at all. Rather, I wanted to discuss
whether arbitrarily allowing VOID keys (but not, say, also CHAR keys) in
addition to properly typed ones makes sense.
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).
Well, yes, but all of these problems are already there as soon as you
use pseudo real numbers. They are not introduced by the use of a map.
Why not have some faith in the future users of the map? They may know
of these problems and still have a perfectly good reason to use double
or float as map key.
I just thought that if Map is already restricted on what key types it
supports, it might make sense to also rule out floating point types (as
supporting them might cause more trouble than it is worth it). If
anybody thinks differently, fine with me. (However, if you do support
floating point types, you should clarify what equality relation to use
for them, the one at
<http://udk.openoffice.org/common/man/typesystem.html> that implies
NaN==NaN or the one required by IEEE and implemented by your typical
programming language, where NaN==NaN does not hold.)
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
