zeroshade commented on issue #269: URL: https://github.com/apache/arrow-go/issues/269#issuecomment-2741543787
> do you think the new weak pointer and cleanup function features in go 1.24 would make it possible to avoid needing the Release and Retain paradigm? In my experience, figuring out when it is necessary to call those trips up a lot of people and wasted time debugging early calls to Release. It's definitely possible, and something I'd be very interested in pursuing. There are two drawbacks I can think of: 1. AddCleanup is non-deterministic on when it runs, so for situations where the user is using a custom allocator (instead of the default Go allocator) we'd still want to make sure that the Retain/Release paradigm allows users to control *when* memory is freed 2. It's also not guaranteed to run before program exit, which may not be a problem given that typically it's just calling Free on some allocations so maybe this isn't an issue. Would you be willing to sketch out a potential design for shifting to using weakptr and addcleanup? > Additionally, I agree with @maxpoletaev's point about too many types and subpackages. There doesn't seem to be a lot of reason as to why some types are in `array` and some are in `arrow`. Maybe less subpackages (or none) would make sense? I mean, given the size of the codebase, the subpackages are definitely needed for some organization. Typically the individual Array types (e.g. an Int8Array) are in the `array` package with the interface they are implementing, `arrow.Array`, being in the top-level `arrow` package. (Much of this was simply inherited from the original implementation of this package and then following that pattern). Can you give me an example of some types that seem to not make sense to exist in the `array` package? That said, I'm not opposed to restructuring the package and its subpackages in terms of where things live and how it works (for instance, I've started to attempt to restructure the `decimal` stuff to shift from the separate `decimal128` and `decimal256` packages into a unified `decimal` package, and so on). Essentially, I'm asking for suggestions as to what specific shifts and changes you think would be helpful. I'm very aware that we need better documentation and more examples in here, but as for the organization of which subpackage certain things live in, I definitely need suggestions since I've been deep in here so long that the package organization seems natural to me :smile: haha. -- 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: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
