Convention for read-only array getters

Internals & Design
22

I have created a repo that is a baseline specification of what was discussed GitHub - bkamins/ReadOnlyArrays.jl: A wrapper type around AbstractArray that is read-only. I came to the conclusion not to include indexing when creating the read-only array, as we can always wrap a view if needed.

4 Likes
23

As we are considering including GitHub - bkamins/ReadOnlyArrays.jl: A wrapper type around AbstractArray that is read-only in DataFrames.jl and CategoricalArrays.jl we want to make sure that we would follow a more widely accepted approach. Therefore it would be great if we got the feedback from the community in the following areas:

  1. is the provided functionality useful (of course the details can be changed later);
  2. if yes then where it should be kept:
    a. as is
    b. the repo should be moved to some organization on GitHub, as a separate package
    c. the functionality should be included in some existing package

Tank you.

24

I gave it a glance (heading out). People getting a ReadOnlyArray may not know that it is a ReadOnlyArray even though they will not write it. For that reason, please assure that the usual view, @view constructs (as may be appropriate) passthru or subselect a view/ReadOnlyArray as the client invocation indicates.

Consider asking JuliaArrays if they would be a suitable home (and one that would facilitate overall alignment with future intent).

25

Thank you for the comment.

Regarding:

Do you mean that view of ReadOnlyArray should create a view of its parent and then wrap it again in ReadOnlyArray to avoid excessive nesting of wrappers?

CC @mbauman - any opinion on this?

26

I wouldn’t worry about it. Folks are now used to seeing view(::ReadOnlyArray, ...), for example.

1 Like