If you're able to define a `size` method for the Associative types, then I'd call them all AbstractArrays. I'd use a wrapper type like the last example in http://docs.julialang.org/en/release-0.4/manual/interfaces/#abstract-arrays. You could parameterize the `data` field so any associative type could be wrapped. As a bonus: now it works like an array in Base code, too, without changing any signatures.
But Unions are fine to use in method signatures — there's no penalty there. I think the only place where you'll see a penalty is if you use a Union as a field type in a performance-critical object. That's not unique to Unions… you just want those fields to have concrete types: http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-fields-with-abstract-type. On Wednesday, April 13, 2016 at 1:14:42 PM UTC-4, James Fairbanks wrote: > > Over at LightGraphs we have been discussing support for collections > indexed by integers that can be either dense like Vector{T} or sparse like > Dict{Int,T}. > The idea is that you want to collect some T's together indexed by a range > of integers 1:n. Often you will have a value for all or most of the indices > and should use a Vector{T} for that case. But sometimes you will only have > a few values and don't want to allocate O(n) storage just to hold a much > smaller amount of data. > > What is the best way to express this in types? Does > Union{Associative{Int,T}, AbstractArray{T}} express this with no > performance penalty? Is there any reason to avoid Union types? > > Thanks, > James >
