-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Local
-
None
-
?
-
20
-
537
-
Not Needed
-
Kotlin Beta sprint 44, Kotlin Beta sprint 45, Kotlin Beta sprint 46, Kotlin Beta sprint 47, Kotlin Beta sprint 48
Follow the pattern of managed/unmanaged used for lists by using delegates.
An oversimplified API would look like this:
// Internal until we support multi-typed keys internal interface RealmMap<K, V> : MutableMap<K, V> // Public interface interface RealmDictionary<V> : RealmMap<String, V> // Internal implementation for unmanaged dicts internal class UnmanagedRealmDictionary<V>: RealmDictionary<V>, MutableMap<String, V> by mutableMapOf() // Internal implementation for managed dicts internal class ManagedRealmDictionary<V>( val nativePointer: NativePointer ): AbstractMutableMap<String, V>(), RealmDictionary<V> { // TODO } /** * Instantiates an **unmanaged** [RealmDictionary]. */ fun <V> realmDictionaryOf(vararg entries: Pair<String, V>): RealmDictionary<V> = UnmanagedRealmDictionary() /** * Instantiates an **unmanaged** [RealmDictionary] containing all the entries of this dictionary. */ fun <V> Map<String, V>.toRealmDictionary(): RealmDictionary<V> = TODO()
Observations:
- the C-API is still missing a large number of methods and implementations, e.g. keys, values, find, remove_all, contains and perhaps more.
- the majority of methods from the MutableMap interface are already provided by AbstractMutableMap though they might not be optimised, e.g. putAll iterates over all values in the provided collection and then call put.
- the entries property returns a MutableSet which might be a slight annoyance since we don't need to enable mutability for said set - it can probably be overridden to throw an exception if users decide to modify it.
- It doesn't seem necessary to rely on Mixed as the transport solution since the C-API accepts realm_value_t structs, just as RealmList does.
- depends on
-
RCORE-870 [C-API] implement support for Set and Map
- Closed