# Taking the array indexing interface seriously

**URL:** <https://discourse.julialang.org/t/taking-the-array-indexing-interface-seriously/32035>\
**Category:** Internals & Design\
**Tags:** question\
**Created:** [December 9, 2019, 4:42am UTC](https://discourse.julialang.org/t/taking-the-array-indexing-interface-seriously/32035 "2019-12-09T04:42:53Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [December 9, 2019, 2:02pm UTC](https://discourse.julialang.org/t/taking-the-array-indexing-interface-seriously/32035/17 "2019-12-09T14:02:48Z")

</div>

@fabiangans thinking about what you said a separate interface for disk-based arrays is really something that is missing here.

An `AbstractDiskArray` that follows `AbstractArray` indexing correctly, but defines more sensible baviors for disk-backed array-like data - like avoiding the issues with `show` or broadcast. Traits could be used for chunking? There are quite a few formats that could benefit from this. It would definitely make writing GeoData.jl a lot easier.

BTW I think some of the issues mentioned for HDF5.jl may also apply to Zarr.jl - the indexing doesn’t exactly match `AbstractArray`

---

_[View the full topic](https://discourse.julialang.org/t/taking-the-array-indexing-interface-seriously/32035)._