I am considering refactoring the Dart code in the ICE Code Editor. So far, so good with extracting dialogs and sub-menus out of private methods and into classes. I started with the extracted class in the same file as the original class. The
full.dart
file contains:part of ice; class Full { /* ... */ } class ProjectsDialog { /* ... */ } _hideMenu() { /* ... */ } _hideDialog() { /* ... */ }As the “part of” directive at the top indicates, this is part of the library's main file,
ice.dart
:library ice; // library import statement... part 'editor.dart'; part 'store.dart'; part 'gzip.dart'; part 'full.dart';I am inclined to make the
ProjectsDialog
class part of the full.dart
code:part of ice; part 'full/projects_dialog.dart'; class Full { /* ... */ }That will not work, though. Dart files can only be part of libraries, not other parts. Even if they could, I would still effectively be importing the
ProjectsDialog
class in to the main library.I suspect that I may want to split the ICE package into not one, but two libraries. The first would be for the full-screen version of ICE and would be imported into other code as
import 'package:ice_code_editor/full.dart'
. The second would be the embedded version and would be imported as import 'package:ice_code_editor/embedded.dart'
. Both libraries could then share things like the underlying Editor
, Gzip
and Store
classes.Still, I am unsure if that is necessary and I have not even started on the embedded version of the code, so I will wait to do that another day. For now, I still need to figure out how to organize things and how to keep the
ProjectsDialog
hidden from the outside.I move the
ProjectsDialog
into a new file: full/projects_dialog.dart
, which is part of the main ICE library:part of ice; class ProjectsDialog { /* ... */ }Then, in
ice.dart
, I complete the part/part-of pair:library ice; // other imports here... part 'editor.dart'; part 'store.dart'; part 'gzip.dart'; part 'full.dart'; part 'full/projects_dialog.dart';And, since
full.dart
and full/projects_dialog.dart
are both part of the same library, the Full
class can still use ProjectsDialog
as before.That seems fine, but how can I hide
ProjectsDialog
from the outside world? I suppose that I do not need to prevent access from the outside world—it does not need to be private. Maybe it is sufficient to keep it out of the public documentation:That can be fixed with an internal tool,
tool/dartdoc
, that generates specialized documentation:#!/usr/bin/env sh dartdoc \ --package-root=packages \ --exclude-lib=js,js.wrapping,meta,metadata \ lib/ice.dart mv docs/ice.html docs/dev.html cat docs/dev.html | \ grep -v Dialog.html | \ grep -v ice/Ace \ > docs/ice.htmlWith that, I have a simple solution for de-publicizing my internal classes:
That seems a reasonable approach. I can now extract as many menu and dialog classes as I like without polluting the documentation.
Day #762
No comments:
Post a Comment