starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-07 05:34:35 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

Async and API #756

New Issue
Open
opened 2026-01-29 22:17:07 +00:00 by claunia · 2 comments
claunia commented 2026-01-29 22:17:07 +00:00
Owner
Copy Link

Originally created by @adamhathcock on GitHub (Jan 13, 2026).

Originally assigned to: @adamhathcock on GitHub.

I've been just adding new Async implementations that mostly sit along side the older sync implementations. While I hate the duplication, it is what it is.

However, I have come to the conclusion that users should be guided down the Async path instead of the Sync path by interfaces:
IAsyncArchive vs IArchive
IAsyncReader vs IReader
IAsyncWriter vs IWriter

For example, doing Open on ArchiveFactory or RarArchive returns an IArchive now instead of RarArchive and doing OpenAsync returns IAsyncArchive. It's still a RarArchive but the interfaces enforce the async vs sync implementations now.

Questions:
Is this even good?
Should OpenAsync be actually a ValueTask since dotnet naming wants that? Another naming scheme?

I can close since it's being worked on to do this more breaking and proactive: https://github.com/adamhathcock/sharpcompress/issues/992

Originally created by @adamhathcock on GitHub (Jan 13, 2026). Originally assigned to: @adamhathcock on GitHub. I've been just adding new Async implementations that mostly sit along side the older sync implementations. While I hate the duplication, it is what it is. However, I have come to the conclusion that users should be guided down the Async path instead of the Sync path by interfaces: `IAsyncArchive` vs `IArchive` `IAsyncReader` vs `IReader` `IAsyncWriter` vs `IWriter` For example, doing `Open` on `ArchiveFactory` or `RarArchive` returns an `IArchive` now instead of `RarArchive` and doing `OpenAsync` returns `IAsyncArchive`. It's still a `RarArchive` but the interfaces enforce the async vs sync implementations now. Questions: Is this even good? Should `OpenAsync` be actually a `ValueTask` since dotnet naming wants that? Another naming scheme? I can close since it's being worked on to do this more breaking and proactive: https://github.com/adamhathcock/sharpcompress/issues/992
claunia added the enhancement label 2026-01-29 22:17:07 +00:00
claunia commented 2026-01-29 22:17:08 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Jan 15, 2026):

I think I'm gonna go with:

OpenAsyncArchive and OpenArchive instead of OpenAsync and Open

It's clearer and avoid's the convention of Async meaning the method is asynchronous

@adamhathcock commented on GitHub (Jan 15, 2026): I think I'm gonna go with: `OpenAsyncArchive` and `OpenArchive` instead of `OpenAsync` and `Open` It's clearer and avoid's the convention of `Async` meaning the method is asynchronous
claunia commented 2026-01-29 22:17:08 +00:00
Author
Owner
Copy Link

@adamhathcock commented on GitHub (Jan 15, 2026):

Some follow up fixes and changes here: https://github.com/adamhathcock/sharpcompress/pull/1131

@adamhathcock commented on GitHub (Jan 15, 2026): Some follow up fixes and changes here: https://github.com/adamhathcock/sharpcompress/pull/1131
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#756
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?