Survey of HelpSystem

> Someone asked about how hard it would be to port HelpSystem. Find below my
> survey of the code. I'm going to try to get it ported today, and I'll
> report back to the list if I run into anything tough (most likely
> differences in Morphic.)
>
> Well, let's have a look. In Squeak 4.3 there are 4 packages related to
> HelpSystem. One is a test suite, one is the core of the help system, and
> two are packages which appear to be help content (Help-Squeak-Project and
> Help-Squeak-TerseGuide.)
>
> I wouldn't count the test suite against the total complexity of HelpSystem.
> So there's just one package to examine, which has five categories and one
> extension method. Here's the extension method:
>
> Class>>asHelpTopic
> ^SystemReference forClass: self
>
> That's not too bad, and actually pretty elegant. Here are the categories:
>
> HelpSystem-Core-Builders (4 classes)
> HelpSystem-Core-Help (4 classes)
> HelpSystem-Core-Model (1 class)
> HelpSystem-Core-UI (3 classes)
> HelpSystem-Core-Utilities (3 classes)
>
> I'm going to cover each category in turn.
>
> ------------
> Builders
> ------------
> Note that the category name has nothing to do with ToolBuilder AFAIK.
>
> 4 classes: HelpBuilder (which appears abstract, see below) and 3 subclasses
> of it (ClassAPIHelpBuilder, CustomHelpHelpBuilder, and
> PackageAPIHelpBuilder.)
>
> HelpBuilder has five very short instance methods, and one short class side
> method. The instance method #build sends #subclassResponsibility,
> suggesting abstractness.
>
> Its subclasses total 14 instance methods and 1 class method. That seems
> slim for three classes, so there may be a refactoring opportunity here.
>
> -------
> Help
> -------
> 4 classes, none of them have instance methods. They seem to be the supplied
> "help on help" series, and occupy 25 class methods which mostly just answer
> the content as string literals. Makes sense, but I suspect that there may
> be a refactoring opportunity here as well.
>
> ----------
> Model
> ----------
> This seems to be where the meat of it is. 1 class (HelpTopic) with 17
> instance methods and 3 class methods. Not too big a deal.
>
> ----
> UI
> ----
> This is where I'm most likely to run into trouble. 3 classes, 16 instance
> methods, 12 class methods. HelpIcons has no instance methods, and only a
> handful of class methods that store icons. It can probably go. Noting that
> there's really very little code in the UI, and it's not bad looking either.
>
> ------------
> Utilities
> ------------
> 3 classes, 14 class side methods, no instance methods.
>
> --
> Casey Ransberger
>