implement firstindex, lastindex, axes, size, and ndims consistently

[bkamins]

This makes sure we have a complete indexing API for all types we expose. I hope I have not missed anything.

@nalimilan - if you are OK with this approach I will add tests and make it ready for a review.

[nalimilan]

Sure, looks good. Though if Base adds a fallback maybe we won't need all of these?

[bkamins]

Though if Base adds a fallback maybe we won't need all of these?

We need them, because earlier versions of Julia will not have them so this way we maintain consistency and make sure DataFrames.jl codes work on all versions of Julia post 1.0.

---

Also the major decision is if we really want all those methods defined. What I mean is that in Julia Base you now have for example:

julia> size((1,2,3))
ERROR: MethodError: no method matching size(::Tuple{Int64,Int64,Int64})

julia> size((a=1,b=2,c=3))
ERROR: MethodError: no method matching size(::NamedTuple{(:a, :b, :c),Tuple{Int64,Int64,Int64}})

julia> axes((1,2,3))
(Base.OneTo(3),)

julia> axes((a=1,b=2,c=3))
ERROR: MethodError: no method matching size(::NamedTuple{(:a, :b, :c),Tuple{Int64,Int64,Int64}})

so the question is if we define them now for objects in DataFrames.jl - can we have some problems with consistency with Julia Base in the future.

@mbauman, @StefanKarpinski - could you please give some guidance when non-array types are allowed to safely define a method for size and axes? In particular the tricky case is types that allow indexing with multiple types of values (like NamedTuple in Julia Base - we have several such types in DataFrames.jl that allow indexing using column number but also column name for instance).

Thank you!

[bkamins]

@nalimilan - this should be good for a review.

I have come to the following conclusion that for array interface (axes etc.) we should return always integer-based objects.

The issue is that Julia Base sometimes is not clear in distinction between using term "index" and "key" for v in the context of collection[v]. I recommend the following (and now consistently use it):

• "index" is always integer in DataFrames.jl
• "key" is always a natural key for the collection (so it can be an integer, but can be e.g. Symbol for column names)

Also I am strict with size and axes for invalid dimension unless the type is AbstractVector in which case too large dimension produces 1 and OneTo(1) respectively, as this is what Julia Base does.

[bkamins]

CI passes

[nalimilan]

Makes sense. Just a few comments.

[nalimilan]

Do we need these in the end given that a fallback was added to Base?

[bkamins]

this fallback is only in 1.6. I added it to have it also e.g. in 1.0 in case someone in the future uses these functions in user code explicitly.

[nalimilan]

Maybe add a VERSION check? It's always nice to be able to remove code at some point in the future. :-)

[bkamins]

added - checking if I did it correctly is welcome ;). Thank you!

[bkamins]

@nalimilan - does the version check look good to you now?

[bkamins]

Does this PR look OK now?

[nalimilan]

Yes, sorry, for some reason I had missed the notifications.

[bkamins]

I have added NEWS.md entry.

[bkamins]

Thank you!