samtalki commented on PR #603: URL: https://github.com/apache/arrow-julia/pull/603#issuecomment-4918033743
@kou thanks for your patience. just reviewed all comments, force pushed here with relevant changes, and then restacked the 3 follow up PRs with rebases, no meaningful conflicts. Based on the previous PR https://github.com/apache/arrow-julia/pull/594 I had kept `ArrowSchema` and `ArrowArray` as mutable structs as was designed in that PR. This was Copilot's main complaint. I think using immutable C layout structs was actually a very good suggestion, but **_not_** for the reason it listed, as Julia's features eliminate all of the concerns raised by Copilot in practice. I think the main benefit of immutability here is that `ArrowSchema` and `ArrowArray` will be stack allocated now and have no GC overhead. However, I am worried that I may be biased by personal use case -- I simply cannot imagine a situation where I need mutability on the _Julia side_ in place, because I think I will only be concerned about the mutability of the referenced memory location, not the in-process Julia value after it has been loaded. I think I would just write a replacement value back through the pointer/ref ``` array = unsafe_load(ptr) unsafe_store!(ptr, Arrow.ArrowArray(..., C_NULL, ...)) ``` Can you think of any counterexamples to this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
