Hi Stephan,
>> 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?
Since in some sense (and you will probably have a link pointing to some
mathematical paper about the UNO type system which proves that this
sense is non-sense, actually), a VOID any where a Foo-typed any is
expected is more "natural" than a CHAR any at the same place.
> 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).
<sarcasm>So why do we have those types in UNO at all, if using them is
questionable?</sarcasm>
Within the "default implementation", the precision should not be a
problem, in my understanding - here, only values passed from outside are
compared, no actual calculations happen. So, it is left to the client to
care this.
Removing those types because some clients might not be able to do so
does not really sound like a good idea to me.
Side note: Andrey just convinced me to remove the widening conversions
in the key acceptance ...
Ciao
Frank
--
- Frank Schönheit, Software Engineer [email protected] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Base http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
