[squeak-dev] The Inbox: HelpSystem-Core-dtl.110.mcz

Chris Muller ma.chris.m at gmail.com
Thu Aug 8 20:15:05 UTC 2019


> On Wed, Aug 07, 2019 at 05:26:51PM -0500, Chris Muller wrote:
> > +1 for adding #openHelpBrowser, but -1 for overloading #help.  Please don't.
> >
>
> Point well taken. I put #openHelpBrowser into trunk and moved my inbox
> submission to treated.

Cool, thanks.

> > #openHelpBrowser is perfectly descriptive.  JavaDoc was never very useful,
> > we don't need to try to save typing for this feature.  If you
> > disagree, please consider integrating somewhere into the IDE (class menu?)
> > but still use #openHelpBrowser.  The core library should not poach #help
> > from the namespace.
> >
>
> Interestingly and somewhat ironically, the current implementers of #help
> do nothing of direct interest to the hypothetical DynaBook user. They might
> better be renamed to e.g. #helpString.

I saw them too and had that very same thought.  At least they're
app-specific, except ToolBuilderSpec, but its probably fine for now..

> If the selector #help were to be implemented in some way that might be
> directly meaningful to users, then what should it do?

That's a great question.  "help" is such a universal word, the idea of
being able to ask any Object for help feels right, doesn't it?

So which behaviors would we want to encapsulate "generally", and which
hooks to provide enough customization for apps to "do their own
thing"?  On the one hand, it would be nice to provide an apparatus
that apps can hook in to with very little effort which could provide
something like #openHelpBrowser.  On the other, I can see apps and
frameworks wanting to provide their own entirely different solution to
#help, so there'd need to be an overridability at that broader level
too.


 - Chris


More information about the Squeak-dev mailing list