On 03/20/09 15:34, Frank Schönheit - Sun Microsystems Germany wrote:
>>> I also thought about simply requesting to invalidate (as in: will
throw
a DisposedException when used) all enumerators (for keys, values, and
mapping pairs) once the map is modified. Would probably be the most
stringent requirement, but quite reasonable. What do you think?
Not sure whether this is easily implementable, so I would simply stick
to undefined behavior.
It's pretty easy - my implementation already needs to care for a
modified map (I certainly did not want it to interpret "undefined" as
"allowed to crash"), so changing the current behavior to some "dispose"
is possible.
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).
- containsKey, containsValue, get, put, remove: Why the
NullPointerException? Why would an implementation choose not to support
null references to interfaces as keys and/or values? How would
KeySet.has and KeySet.remove handle this?
Not supporting NULL for either keys or values could probably be
justified (for a concrete implementation) by the additional
implementation effort/complexity it would cost. Imagine an
implementation which internally uses the strict weak ordering on allowed
keys (or even allowed values, if it chooses a certain less-than-O(n)
implementation of containsValue) - allowing for NULL keys (values) would
make the implementation more difficult. So the implementor might decide
that that's just not worth it for the intended use cases.
I fail to see how null interface references complicate things here.
Okay, it seems I used the wrong terminology all the time. With NULL, I
actually meant anys being VOID (which don't have a canonical place in a
strict weak ordering). Changing this in the documentation reveals that
NullPointerException is indeed the wrong exception here, so I will
subsume this under IllegalArgumentException, too.
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.
- remove: An alternative would be to let it return Optional<any> and
not raise NoSuchElementException (again, this might be more appropriate
in certain multi-threaded scenarios).
Okay, we have "I would let it return Optional...", "Better let it return
Optional..." and "An alternative would be to let it return Optional...".
Can you decide for one of those? :)
No, the three cases are rather different.
But we certainly do not want only one or two of the three methods return
an Optional, do we?
I do not dare to introduce the Optional here, since in particular for
(known-to-be) immutable maps (which I think will happen quite often),
it's indeed overhead - in the current shape, a client could safely
"ignore" (well: handle ungracefully) NoSuchElementExceptions after
has/get, since they will not happen.
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. Both
exceptions and optional "work," so if you want to stick with exceptions,
that should be no problem...
- create, createImmutable: You need to clarify what "unsupported types"
are.
Done.
- For my tastes, these rules are too arbitrary for this "default
implementation."
Can you elaborate?
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. Also, strict weak orderings for sequence types
over types already covered should also be easy. 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).
The only "unreasonable relaxation" I see at the moment is the widening
conversion for integer types. Again, this is also implementation-driven
(by your disliked "operator>>=( Any, <inttype> )"), but could easily be
changed. I'd be comfortable with removing this relaxation, if you
request it.
I don't mind. ;)
Anything more "too arbitrary"?
No, got you now.
- There is no "the <NULL/> value" in UNO. (Rather, for every interface
type T, there is a null value of that type.)
But <VOID/> is a dedicated value, right?
Yes, the UNO type "void" is inhabited by exactly one value ("unit").
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
