Unify <Foo> and <Foo>Impl classes that are effectively simple enums or data classes #1604

…e data classes The API of `package:native_assets_cli` uses currently a one-size-fits-all approach: * almost every API class is duplicated between a `<Foo>` and `<Foo>Impl` * `package:native_assets_cli/native_assets_cli.dart` exposes `<Foo>` * `package:native_assets_cli/native_assets_cli_internal.dart` exposes `<Foo>Impl` This has a number of issues * The `_internal.dart` is actually a public API: It's used e.g. by flutter tools and breaking changes to it need major version bumps. * A user of the `<Foo>` API doesn't know that such objects are for example * hashable (e.g. go-to-definition to `<Foo>` there's no indication of that), e.g. `DynamicLoadingSystem` makes no mention of it, no `get hashCode` override, ... only in `DynamicLoadingSystemImpl` there is. * have a `toString()` that code can rely on the returned string not changing * ... * It causes code to have to choose between e.g. `OS` and `OSImpl` - which is very confusing as it's just one concept. * It causes code to have to downcast e.g. `os as OSImpl`. => This is a very bad smell, as generally it's an unsafe operation to downcast. * It's code duplication across the api/ and model/ folders, make it harder to navigate in codebase (as one may have to constantly switch between the files), ... One original intention for this seperation may have been to hide all traces of the json protocol in the non-internal version, but I think this is not needed at all, because the protocol itself will be *more* stable than the APIs offered by the package itself (much easier to break the dart API and publish and new version of the package than to break the CLI protocol). => So this PR starts to merge some `<Foo>` and `<Foo>Impl` classes into one `<Foo>`. => This simplifies the code, removes `as ...Impl` downcasts, etc One extra thing this CL does is remove some members from e.g. `OS`. This is part of disentangling the concepts. The build protocol may always expose the target operating system, but it may only expose the target ABI if the building code supports code assets. => So one should be able to use `OS` without `OS.dylibFileName` / `OS.architectures` / ... => We may even decide to move code asset related code into it's own package, making the core build protocol package not need the concept of `Architecture` at all.

…fig is a plain data class)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Unify <Foo> and <Foo>Impl classes that are effectively simple enums or data classes #1604

Unify <Foo> and <Foo>Impl classes that are effectively simple enums or data classes #1604

Commits on Sep 27, 2024