API clarification request: space/time complexity of rows(table) and columns(table)

[tkf]

Does Tables.rowaccess(table) == true/Tables.columnaccess(table) == true mean Tables.rows(table)/Tables.columns(table) is O(1) (with reasonably small constant)? Current documentation is not super clear about this aspect:

Tables.jl/README.md

Line 60 in 59de960

* Define `Tables.rowaccess(::Type{<:MyTable}) = true`: this signals that `MyTable` supports iterating objects that satisfy the `Row` interface; note this function isn't meant for public use, but is instead used by Tables.jl itself to provide a generic fallback definition for `Tables.columns` on row-oriented sources

Tables.jl/README.md

Line 66 in 59de960

* Define `Tables.columnaccess(::Type{<:MyTable}) = true`: this signals that `MyTable` supports returning an object satisfying the `Columns` interface; note this function isn't meant for public use, but is instead used by Tables.jl itself to provide a generic fallback definition for `Tables.rows` on column-oriented sources

(This is something I noticed while looking at #131. But I just realized that this already existed before that PR.)

[quinnj]

As far as I'm aware of various implementations of Tables.rows/Tables.columns, yes, this is a O(1) operation. I'm not exactly clear on the request here: that it be required as part of the API that it be O(1)? Or that it just mention when implementing that it should be? It kind of naturally falls out of the definition that if you define Tables.rowaccess/Tables.columnaccess, then your provided Tables.rows/Tables.columns functions will usually just return the input object (since the interface functions tend to be implemented on the table type itself); the other common case is when you have some kind of wrapper/lazy operation object, which may just return the wrapped table.

[tkf]

Yes, it'd be nice to mention that the Tables.rows(table) and Tables.columns(table) must be O(1) when the corresponding Tables.rowaccess(table) and Tables.columnaccess(table) are defined to be true.

I agree it's natural but I thought it'd be nice to clarify it. Someone may implement Tables.columns that is better than the fallback but still copies the data.