haf
ZipEntry accessors and inheritance
I couldn't find a previous issue addressing this as a cursory glance did not reveal similar issue.
This is more of a discussion question around the interface and high-level implementation of ZipEntry.
To start, why is ZipEntry from ZipInputStream not a separate, base class of the ZipEntry acquired from ZipFile? (That spurs a follow up I will note further below)
The current 'interface' allows for methods that cannot be used when working with a directly instantiated ZipInputStream (where the ZipEntry must be provided from a ZipFile to use Extract(), for example). While this is documented, it makes for a very cluttered intellisense experience and requires more documentation reading and experimentation to figure out how ZipInputStream was intended to be used. For example, using ZipInputStream, it is not immediately obvious how to do something as simple as filtering one zip into a new zip without the use of the filesystem. My guess as to why this is, is that the performance heavily depends on seeking streams to a file handle instead of doing everything in memory (let me know if that sounds right).
So to follow up on the initial question, I predict a concern with the proposal arises around reusability of ZipInputStream (because writing and maintaining a ZipInputStream for two ZipEntry types as proposed could be a nuisance). I don't know if generics would be a good solution or if a derived ZipInputStream for ZipFile entries would suffice. But either seems preferable (as a consumer of the package) to seeing unusable methods being presented via intellisense.
