dart-lang / native / 11088091654

90%

Build Type

push

github

Committed by web-flow

Commit Message

Unify {OS,Architecture,...} and {OS,Architecture,...}Impl classes that are effectively simple enums or data classes (#1604)

The API of `package:native_assets_cli` uses currently a
one-size-fits-all approach:

* almost every API class has two versions a `<Foo>` and a `<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 separation 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` downcas... (continued)

Run Details

45 of 46 new or added lines in 4 files covered. (97.83%)

35 existing lines in 3 files now uncovered.

3069 of 3356 relevant lines covered (91.45%)

32.32 hits per line