Hi Stephan,
>> However, Andre Fischer (offline) raised concerns about multi-threading
>> usage of the whole interface. That is, since all three enumerators
>> (potentially) stop working as soon as the map is modified (e.g. by an
>> external instance), they become pretty useless as long as you cannot
>> lock the complete map while enumerating it - which you cannot.
>
> You *can* do it (with a protocol on top of using a given XMap instance).
Sure, but that notably complicates the usage, and is error-prone, since
it hard, up to impossible, to ensure everybody conforms to the protocol.
So, I really think Andre has a good point here, and I am tempted to
change enumerations to work on a copy.
> I still do not understand. There are two cases where void any values as
> keys would be valid---if KeyType is "void" and if KeyType is "any". In
> the first case, a strict weak ordering is trivial. In the second case,
> allowing void any values (in addition to all the other any values) does
> not further complicate a strict weak ordering.
KeyType "void" is nothing I would support - a map which can hold at most
on entry seems somewhat useless to me.
KeyType "any" is also nothing I would support (in the default
implementation): I simply cannot imagine a strict weak ordering which
could be implemented with a reasonable effort, and I do not think an
unreasonable effort, or an implementation not using strict weak
orderings, and thus being O(n), is worth it.
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.
>> What about adding an XConcurrentMap, having
>> - Optional< any > getIfPresent( [in] any Key );
>> - Optional< any > putIfAbsent( [in] any Key, [in] any Value );
>> - Optional< any > replaceIfPresent( [in] any Key, [in] any Value );
>> - boolean replaceIfMapped( [in] any Key, [in] any OldValue,
>> [in] any NewValue );
>
> I would not complicate the (already large) interface further.
Glad to hear that ;), though I admit I found the idea of XConcurrentMap
tempting ...
> Both
> exceptions and optional "work," so if you want to stick with exceptions,
> that should be no problem...
okay.
>> The only "unreasonable restriction" I see at the moment is that certain
>> key types are rejected - notably those which do not have a canonical
>> strict weak ordering. I admit this is implementation-driven ... Would
>> you require this to be changed?
>
> Strict weak orderings for void, unsigned short, unsigned long, unsigned
> hyper should be easy.
Sorry, forgot to mention (in both the mails and the doc) that unsigned
types are of course supported, too.
> Also, strict weak orderings for sequence types
> over types already covered should also be easy.
Ah, indeed, those could be added easily. Will perhaps do it.
> 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?
Thanks & 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]
