As I browse through the algorithms, I've noticed that certain files (src/utils.dart, src/ufixnum.dart, src/registry/registry.dart) are imported by nearly every algorithm. If we create a simple internal library that exports all of these files, we can probably clean up imports (import one thing instead of 3-4).
This library could also use typedefs to better match up with Java types (e.g. Array -> List, Long -> Int64, Int -> Int32). The latter two match up with https://pub.dev/packages/fixnum (#25)
I can think of other uses for this "internal library": extension methods to match common cryptographic applications, or defining classes that are used in BC but not available in PC (Pack, for example).
Note that the second paragraph is dependent on https://github.com/dart-lang/language/issues/65, which should come out in a couple months or so. Since this issue is decidedly high-level and not strictly necessary, that about matches my suggested timeline for implementation.
As I browse through the algorithms, I've noticed that certain files (src/utils.dart, src/ufixnum.dart, src/registry/registry.dart) are imported by nearly every algorithm. If we create a simple internal library that exports all of these files, we can probably clean up imports (import one thing instead of 3-4).
This library could also use typedefs to better match up with Java types (e.g. Array -> List, Long -> Int64, Int -> Int32). The latter two match up with https://pub.dev/packages/fixnum (#25)
I can think of other uses for this "internal library": extension methods to match common cryptographic applications, or defining classes that are used in BC but not available in PC (Pack, for example).
Note that the second paragraph is dependent on https://github.com/dart-lang/language/issues/65, which should come out in a couple months or so. Since this issue is decidedly high-level and not strictly necessary, that about matches my suggested timeline for implementation.