Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a minimal public API #73

Open
gmethvin opened this issue Jan 26, 2021 · 0 comments
Open

Define a minimal public API #73

gmethvin opened this issue Jan 26, 2021 · 0 comments

Comments

@gmethvin
Copy link
Owner

gmethvin commented Jan 26, 2021

It would make sense to separate the public API from other libraries used internally. This way it's clear to users which API they should be using, and we can minimize breaking changes only to that API.

The following things should be public:

  1. A builder for the DirectoryWatcher that provides all configuration functionality. As part of this we could possibly make DirectoryWatcher an interface, but I'm not sure that's really necessary if we make the constructor private. I don't see a use case for alternative implementations.
  2. DirectoryChangeEvent. This could possibly be an interface to make it easier to restructure the class hierarchy in the future.
  3. The DirectoryChangeListener interface.
  4. The FileHasher interface and some built-in implementations—but not the underlying implementation classes.
  5. A FileHash interface that defines a minimal API for file hashes and utility methods for creating FileHash instances.
  6. The MacOSXListeningWatchService and related classes. We might be able to extract some interfaces to minimize the public API here as well.

The remainder of the classes could either be made package-private or moved to an internal package. I think the latter might be more convenient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant