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

Avoid @sealed annotation, using final class for everything #105

Open
jonasfj opened this issue May 6, 2024 · 3 comments · May be fixed by #172
Open

Avoid @sealed annotation, using final class for everything #105

jonasfj opened this issue May 6, 2024 · 3 comments · May be fixed by #172
Labels
cleanup enhancement New feature or request good first issue Good for newcomers

Comments

@jonasfj
Copy link
Member

jonasfj commented May 6, 2024

We should use final class for everything in the public API.

Motiviation:

  • This package is not attempting to offer abstractions over cryptographic APIs.
  • We don't want others to implement the types we offer.
  • We also want the option to add more method to the types we offer in the future, without breaking API compatibility.

In practice, we might have to do something that we export from src/webcrypto/webcrypto.dart and something we only export to other libraries inside this package.

// This is exported from lib/webcrypto.dart
// This means that in lib/webcrypto we have to use "show"
// to avoid exporting KeyPairBase.
// Example:
//   export src/webcrypto.dart show KeyPair;
abstract final class KeyPair<S, T> {
  /// Private key for [publicKey].
  S get privateKey;

  /// Public key matching [privateKey].
  T get publicKey;
}

// This is not exported from lib/webcrypto.dart
// but implementations for different platforms can import this from
// src/webcrypto/webcrypto.dart
// and extend it inorder to implement KeyPair
abstract base class KeyPairBase<S, T> extends KeyPair<S, T> {}
@devenderbutani21
Copy link

Hello! I would like to work in this issue.

@jonasfj
Copy link
Member Author

jonasfj commented May 8, 2024

Assigned to you.

This is mostly a bit of refactoring and making sure the public API is pretty, while also making sure people accessing it can't implement our classes :D

@jonasfj
Copy link
Member Author

jonasfj commented May 8, 2024

Might I suggest trying it out on something simple like HmacSecretKey, making a WIP (draft) PR, so that we can decide if we like that pattern before we apply the same pattern consistently across all public classes.

side note. we'll probably also need to bump the version number and write an entry in CHANGELOG.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants