David van Leeuwen

Thanks, that idea crossed my mind, too. That is probably easiest.

The `zeros` and `ones`, are fixed now, but `cat` c.s. is non-trivial. Consider ```julia julia> n = NamedArrays.NamedArray(rand(3), [DataStructures.OrderedDict(:a => 1, :b =>2, :c =>3)]) 3-element Named Array{Float64,1} A │...

So currently, a `vcat(n, n)` generates names `"1"` ...`"6"` for dim `A` in the case above. Of course in this particular case they could have been named `Symbol("1")` etc., to...

The original names can be anything, not just symbol or string, so I don't see how a general sensible naming scheme can be devised. `promote_type(String, Symbol)` is `Any`, I can't...

It looks like the code in `view(::NamedArray)` is a bit of a hack to get it going, not understanding much of the workings of `view()`. ```julia Base.view{T,N}(n::NamedArray{T,N}, I::Vararg{Any,N}) = namedgetindex(n,...

I think the whole idea about a view is that only indices are recomputed in accessing individual elements in the view. So `view(NamedArray(::Array))` should probably translate `NamedArray(view(::Array), view(dicts))` somehow.

It would be possible for a name to stay in the (unchanged) dict, but point to an index outside the view. I would say I would have to study the...

What is the advantage of having a getter like that over accessing the field? Would `Array()` work for you? ---david ( 大卫) Op 27 jun. 2017 13:46 schreef "Diego Javier...

I can't really look into the future that well. Personally I don't know what the julia idiom is for these kind of type-conversion functions. I thought things like ```julia n...

Did you try a `Pkg.update()` to be sure `Combinatorics` in the latest version? BTW I just submitted a PR to METADATA to include a v0.6-compatible version of `NamedArrays`.