Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I've come across the zip example bevor, and even considered adding support for mutable access to the owner here https://github.com/Voultapher/self_cell/pull/36. See the last comment why I decided not to pursue this. Looking at the specific example, really what is the purpose of storing the lazy ZipReader result? IMO that's bit of bad design on the part of the zip crate. The stdlib APIs consume reader, allowing you to abstract over creation logic. If what you need to store, needs further pre-processing, why not pull that out? Specifically here, what is the point of having a self-referential struct that contains an owner ZipArchive that you will no longer be allowed to mutate. And a lazy reader ZipReader that you can then use to really read the file? If you need to abstract over the construction logic you could return (ZipArchive, Box ZipReader>), if you want to return the content you can return (ZipArchive, Vec) allowing further use of ZipArchive.