Naming
There is a separate page for discussion of
? is very different from SWIG's use of it" href="tiki-index.php?page=Typemap+renaming+proposal" class="wiki">renaming TypeMap.
Documentation
The documentation needs to be clear on the point of what happens when a put operation implies changing the type of data associated with a given key. Such a put must generate an exception for type-correctness. If the user still wants to override the type associated with they, the element should first be remove()d then set with a new type and value.
Extension to allow object members
The gov.cca.Type enum could be extended to include Object and Object Array with methods
sidl.BaseInterface getObject(in string key, in sidl.BaseInterface defaultObject);
void putObject(in string key, in sidl.BaseInterface object);
array<sidl.BaseInterface> getObjectArray(in string key, in array<sidl.BaseInterface> defaultObjectArray);
void putObjectArray(in string key, in array<sidl.BaseInterface object);
Open issues and proposed resolutions:
Serialization: Objects put in TypeMaps may not be serializable.
Resolutions: Entries which do not fully implement sidl.io.Serializable are simply ignored; alternatively Entries which are not serializable come out on the other end with identical key but nil value. In either case, a non-Serializable object is NOT considered an exception.
Copying: Objects put in TypeMaps are reference counted, so all copy is by reference.
TypeMap as Event Payload: Objects put in maps used as event payload must not be tampered with by a recipient or the typemap cannot be reused for multiple recipients.
Resolutions: TypeMaps can have a number of alternative data locking schemes added.
Alternative data locking schemes
In all the following, lock violation is considered an exception, generally indicating that the user didn't read the docs for the interface that gave them the map which generated the exception.
Advisory Open/Close at map instance level
Provide map-scoped advisory locking by a pair of public functions
void lockMap();
void unlockMap();
An internal state variable keeps track of the lock status. No changes to the map
data are permitted when locked. The user is free to screw up and unlock a map received during event processing.
Permutations: The user might or might not be allowed to add new key:value pairs to the map under the claim that 'changes to the (existing) map data' are not done by adding new data.
Advisory locking at key:value level
An internal state variable keeps track of the lock for each data pair, rather than the map as a whole. Otherwise the same as the previous advisory scheme.
void lockKey(in string key);
void unlockKey(in string ky);
Marginally stronger locking
For finer-grained and somewhat less accident prone access control, the lock/unlock functions could be changed to require a lock token. This would be an integer magic number that usually only the setter of a lock would know. Obviously, a user determined to bypass the lock can do so by writing a loop over all possible tokens and catching the exceptions for all the failures. The simplest interface would be
void lockKey(in string key, in int token);
void unlockKey(in string key, in int token);
However these admit a race condition and if we want to be multithread friendly, we must add the token to put operations on the map. The existing put operations would continue to exist and would generate exceptions if a lock was found.
The advantage of this scheme is that it allows multiple entities with interests in a particular map (say the properties assigned to a component instance by various tools) to manage independent subsets of keys. If a conflict between tools exists, an exception will bring this to someone's attention.
Add your favorite permutation on locking here (unless it involves cryptography)