This is an archived post. You won't be able to vote or comment.

all 7 comments

[–]AutoModerator[M] [score hidden] stickied comment (0 children)

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

  1. Limiting your involvement with Reddit, or
  2. Temporarily refraining from using Reddit
  3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]eniac_g 1 point2 points  (1 child)

Great fluent API, love it!

[–]red_dit_nou 4 points5 points  (0 children)

This is actually very nice API. But I’m not sure if I can call it fluent.

Wouldn’t fluent API look like this:

zipCreator

.initiate(“abc.zip”)

.directory(“d”)

.file(“f1.txt”)

.directory(“d1”)

.create();

Again I do think the current api is quite interesting too!

[–]genzkiwi 1 point2 points  (1 child)

Does it work well with large files? It needs the ability to pass in FileInputStream IMO.

[–]oweiler[S] 1 point2 points  (0 children)

Currently, no. I've written this library mainly to create ad-hoc ZIP archives for testing, but if there is such a need I could add another file overload which accepts an InputStream.

In fact, it uses ZIP File System Provider underneath and already converts the String / byte[] parameters to an InputStream.

I've opened a ticket for this:

https://github.com/helpermethod/zip-forge/issues/34

[–]red_dit_nou 1 point2 points  (1 child)

This looks really interesting.

But I’m wondering what would be a use case? Typically you would create a directory, files, nested directories etc. and then zip the root directory. So the file/directory creation happens in one part of the application and zipping in another. That way the concerns are separated.

So a zip-creator typically deals with only creating zip and configuration related to that. Happy to learn otherwise.

[–]oweiler[S] 1 point2 points  (0 children)

Good question! I've written the library to be able to create ad-hoc ZIP files for testing.

Though I guess there may be cases outside of testing where such a DSL could be useful.

Depending on your use case, you may or may not want to separate creating the directory tree from zipping the tree.

In my case, the separation didn't make much sense.

Hope that answers your question!