Open cscherrer opened 2 years ago
Thanks @cscherrer.
This also seems natural with Dictionary
and its values. It's worth stating that a downside to this is that there is annoying increase in verbosity to the types, compared to Base.Set
and Base.Dict
. This could possibly be severe enough that it is worth having this functionality as an entirely new type, even. (For context, I still consider much of this work as prototyping behavior that potentially could be ported to Julia 2.0, so we need a similar level of polish and simplicity as Base
).
The one thing we have at the moment that I'd really like to preserve is that we can state whether a dictionary is issettable
or isinsertable
. Now this will depend on the underlying arrays. Before moving forward I think we need to make a plan for this. To handle arrays and dictionaries gracefully, I have been considering the following body of work:
new
and new_type
functions (note - names are placeholders, basically these are generalized versions of collect
except in new(T, values)
the T
is the container type not the element type as in collect(T, values)
)new_type
, similar_type
and empty_type
for arrays.isinsertable
and issettable
for arraysisinsertable(inds::Indices) = isinsertable(inds.values)
, etc.Any thoughts around this would be appreciated. (CC @c42f).
Also - we currently have a contrib
directory where stuff people want to play with could live.
I think we could rename this to src/experimental
, with the idea that we'd accept all sorts of containers-in-progress and experimental APIs there, and have them as unexported types and docstrings saying they are experimental. The unordered hash dictionary for example is still quite useful. We'll need to create a WeakKeyDictionary
. I want to make sure the token interface works with sorted dictionaries (trees and such).
Thanks @andyferris, I appreciate the care you're taking in thinking through this. I wasn't aware of the Julia 2.0 plan, but that sounds like it could work out great :)
Putting it in contrib
or experimental
would be fine for me. Any ideas for a name for this? It more abstract than Indices
, but still a concrete type, so I'm not sure what to call it.
I wasn't aware of the Julia 2.0 plan
To be clear this is more of a personal wish than an agreed-upon plan :)
I haven't thought of any good name. CustomIndices
? GenericIndices
? Also, feel free to use a single-character prefix.
Another approach is to add CustomIndices
(or whatever) and maintain an exported const Indices{I} = CustomIndices{I, Vector{I}}
?
This PR makes a small change to generalize
Indices
, replacingwith
The idea is to allow values stored in other formats, for example a
StructArray
orTupleVector
. I think this will be a step toward being able to implement something like