Open schlichtanders opened 3 years ago
I have only recently started to formalize this with empty_type
. This is the current set of "rules":
isinsertable
have a zero-argument constructor. E.g. Dictionary{String, Float64}()
.issettable
have have an undef
constructor like Dictionary{String, Float64}(new_indices, undef)
.view
, filterview
, reverse
, etc) would have a two argument constructor like Dictionary{String, Float64}(new_indices, new_values)
. There would generally be a one-argument constructor Dictionary{String, Float64}(from)
which is just sugar for Dictionary{String, Float64}(keys(from), values(from))
. The values()
is there to support Dict
, but otherwise it's an identity function.When you have a new keytype or eltype that you want to use, there are helper functions. Insertable dictionaries can be created by empty
and you can discover their types via Dictionaries.empty_type
and call the zero-argument constructor from that. Settable dictionaries can be created by similar
and I'd like to introduce a similar_type
function. We also need a type-domain function for 3 above, for when you already know the keys and the values; I don't have a good name for that (for reference, this would be the functional equivalent of StaticArrays.similar_type
which was designed around immutable arrays).
Does that help? I'd like to finish this and write it all up at some point.
yes that helps - I think for my usecase it is fine to fallback to zero-argument constructor for now.
Looking forward to the whole type interfaces!
Hi, sorry if this question is somehow inbetween an discourse question and an issue/feature request.
Is it possible to create a an empty
AbstractDictionary
given the concrete type of the system? I am asking because it seems withinAbstractDictionaries
/AbstractDict
it is especially common to have totally different kind of constructors which hence do not provide a common interface.I see that I can construct empty
AbstractDictionary
, given an instance, but I wasn't able to find one which takes the type instead.