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

Extract Canonicalization from the ModelElement hierarchy #3753

Merged
merged 1 commit into from
Apr 22, 2024

Conversation

srawlins
Copy link
Member

@srawlins srawlins commented Apr 17, 2024

Canonicalization was one of the mixins in the hierarchy that adds to the tangle; it is sometimes extended, and sometimes mixed in. We'll see below that it added undue API into non-ModelElement classes. I extract it here from the type hierarchy. The class remains, but is now instantiated by ModelElement when necessary.

This is mostly a no-op, but there are a few changes that could conceivably lead to different behavior, although I personally cannot conceive of how 😄

  • When calculating a canonicalization score, in calculateCanonicalCandidate, do not split a package name at all (used to be split with locationSplitter). I don't think the package names have ever been split.
  • When calculating a canonicalization score, in calculateCanonicalCandidate, only split a library name by '.' characters (used to be split with locationSplitter). I don't think libraries can contain the other characters.

The refactoring leads to a number of other improvements:

  • Move Canonicalization.isCanonical to Locatable. All Canonicalization-subtyping classes also subtype this mixin.
  • Remove Canonicalization.locationPieces and all implementations. ModelElement.locationPieces can be inlined, and the other implementations were unnecessary; only required to satisfy the contract.
  • Remove unused Nameable.namePart field.
  • Move locationSplitter top-level variable to canonicalization.dart, now the only place where it is referenced.
  • Make MarkdownFileDocumentation implement Warnable, instead of Canonicalization; the class expects a few fields, which are all available on Warnable.
  • Make Package mix-in Warnable, instead of Canonicalization; the class expects a few fields, which are all available on Warnable.
  • Make Documentation._element a Warnable, instead of a Canonicalization.

These hierarchies can probably be simplified further. In particular, I think Locatable and Warnable can be combined. I'd like to explore that later.


  • I’ve reviewed the contributor guide and applied the relevant portions to this PR.
Contribution guidelines:

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

@srawlins srawlins requested a review from kallentu April 17, 2024 16:02
abstract mixin class Canonicalization
implements Locatable, Documentable, Warnable {
bool get isCanonical;
final class Canonicalization {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh nice, no more mixin class. Very good. This was super confusing to me.

@@ -59,7 +59,7 @@ import 'package:path/path.dart' as p show Context;
/// helps prevent subtle bugs as generated output for a non-canonical
/// ModelElement will reference itself as part of the "wrong" [Library] from the
/// public interface perspective.
abstract class ModelElement extends Canonicalization
abstract class ModelElement
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was so weird for me. Glad we're removing this extension.

import 'package:markdown/markdown.dart' as md;

class Documentation {
final Canonicalization _element;
final Warnable _element;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Nothing actionable for this CL, just thoughts)
I think this is better. This reminds me that using the mixin as a type makes code so hard to read. I've come across this Documentation class so many times and had to figure out what class the Warnable was and where that class was instantiated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I agree. I think maybe using mixins as types is what led to some shoe-horning and complexity.

@srawlins srawlins merged commit d9e31ff into dart-lang:main Apr 22, 2024
9 checks passed
@srawlins srawlins deleted the extract-canonicalization branch April 22, 2024 19:11
copybara-service bot pushed a commit to dart-lang/sdk that referenced this pull request Apr 25, 2024
Revisions updated by `dart tools/rev_sdk_deps.dart`.

dartdoc (https://github.com/dart-lang/dartdoc/compare/1ae5b4c..d9e31ff):
  d9e31ff9  2024-04-22  Sam Rawlins  Extract Canonicalization from the ModelElement hierarchy (dart-lang/dartdoc#3753)

webdev (https://github.com/dart-lang/webdev/compare/d4f9f67..50bf268):
  50bf2687  2024-04-24  Elliott Brooks  Add `dwdsLaunch` and `dwdsAttach` events (dart-lang/webdev#2418)
  804eb5c5  2024-04-24  Elliott Brooks  Reset DWDS and WebDev after release (dart-lang/webdev#2419)
  988b03bf  2024-04-23  Elliott Brooks  Prepare webdev for release to version 3.5.0 (dart-lang/webdev#2417)
  68513c8f  2024-04-23  Elliott Brooks  Prepare DWDS for release to version 24.0.0 (dart-lang/webdev#2413)
  0b188169  2024-04-22  Elliott Brooks  Fix test timeouts related to weak null safety (dart-lang/webdev#2416)

Change-Id: Ie366c07cf46d7efb15d67322eac045e6a6bd7fe3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/364522
Auto-Submit: Devon Carew <devoncarew@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
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

Successfully merging this pull request may close these issues.

2 participants