Remove the distinction between mutable and immutable archives #24
Comments
|
Your idea has merit. Zip archive objects don't follow the usual "all changes in memory, then safe-save to disk" behaviour of Foundation containers, they behave more like Core Data objects with incremental updates. I'm all for simplifying the interface if it will ease the burden of working with the API. However:
You can and should pass around and reference archive objects. It's just that the archive entry objects will go invalid when In terms of memory mapping allowing entries to change out underneath them, this is no different from using What do the other watchers think of getting rid of a distinct |
|
No further feedback, so I'm closing the issue. |
* No more separate mutable archive subclass (ref #24). * Initializers and factory methods may now return nil, along with error information. * Initializers now take an options dictionary, which allows for expansion. For now, you can set ZZOpenOptionsEncodingKey for string encoding and ZZOpenOptionsCreateIfMissingKey to create the archive file if it is missing. * Drop the public load: method, as initializers and updateEntries: do any necessary loading. It’s fairly cheap to create a new archive object to reload changed contents, and we no longer lazily load contents and entries. * The redesign prevents creating erroneous objects e.g. file not found may be a legitimate problem, and prevents swallowing of read errors during lazy loading. * Update podspec to version 8.0.
…rties to feature/docx ULYSSES-4821 Translate Section Settings to DOCX * commit 'fc8a022bfe138f7b3408a33879ef3fc74a511930': Adds comment to keyword support Restores iOS compatibility Fixes keyword support Adds support for core properties Adds test case for document properties
In Cocoa, an immutable object is one whose contents cannot change.
For example, an immutable array holds a unchanging list of objects. Yes, properties etc. of those objects might change, but the actual objects referred to does not.
And again
NSDataconsists of a pointer (to some bytes) and a length. Neither of those can change. In rare setups, the memory pointed to can change, but theNSDataobject itself does not.ZZArchivefollows a similar pattern, having a mutable subclass, but oddly does not adhere fully; a regularZZArchivecan be mutated at any time by calling the-load:method.There is little to advantage to having a truly immutable archive; unlike arrays and strings etc. apps do not tend to pass them around too much internally (particularly when memory mapping means entries can have their content changed out underneath them anyhow).
Thus I argue there is no point in having
ZZMutableArchiveas a separate class.ZZArchiveshould be mutable, and that would be it. For apps that do feel the need to pass around archives internally, it's simpler to just agree not to mutate it, or define a protocol and pass around objects promising only that they conform to it.The text was updated successfully, but these errors were encountered: