I don't think there is a problem with having "internal" data structures that provide mutation and other capabilities, but when internal data structures are made external (exported to consumers through "public" C++ APIs / namespaces) then immutability is good there (or at least forcing a consumer to dig into the arrow::Buffer objects if they want to mutate memory).
On Thu, Nov 4, 2021 at 5:11 AM Antoine Pitrou <anto...@python.org> wrote: > > > Le 04/11/2021 à 10:56, Alessandro Molina a écrit : > > On Wed, Nov 3, 2021 at 11:34 PM Jacques Nadeau <jacq...@apache.org> wrote: > > > > > >> In a perfect world we would have done a better job in the object > >> hierarchy/behavior of making this explicit but we don't live in that world, > >> unfortunately. > > > > > > Makes sense, but I thought that was exactly the reason why set/setSafe are > > only available for FixedWidth vectors. > > On those once the size is set it seems fairly safe to mutate them if the > > set methods take care of updating null values too. > > Not if you have multiple threads reading the same data, which is going > to be common in many Arrow applications. To enable efficient access > without thread synchronization, immutable data is almost mandatory. > > So I don't think we should modify the C++ Array APIs to allow for > mutations (as you say, people can say still do dirty things at a lower > level if they want to, and they have to live with the consequences). > > Regards > > Antoine.
