Hi Timothy,

It sounds like you're in an early ideation stage of your help system, which
tends to be a good stage to just let your inhibitions loose and crank out a
skeleton sketch of your vision, leaving details like Object or ProtoObject
to be filled in later (though, I think I know what people will say).  I'm
more curious how you plan to structure your packages -- some kind of
HelpEngine core package into which additional packages can be loaded for
plugging in different content or, content-types, or, even for
different presentation outputs..  Customization via loadability and
unloadability for servers..

So much to consider, it should be fun!

 - Chris


On Mon, May 18, 2020 at 2:43 PM gettimothy via Squeak-dev <
squeak-dev at lists.squeakfoundation.org> wrote:

> Hi Foks,
>
> TL;DR; is it a "BAD THING TO DO" to add a class side method to ProtoObject?
>
>
> ProtoObject >> help
>
> ^'foo'
>
>
> Now every class A to Z in the system has a built in help message:
>
> AColorSelectorMorph help --> 'foo'
> ZoomMorph help --> 'foo'
>
>
> "Smalltalk" is not a class, so figure that out later..plus packages etc.
>
> Smalltalk help
> SmalltalkImage(Object)>>doesNotUnderstand: #help
>
>
> Longer version
>
> I am going to dabble with my idea of re-working help in Smalltalk.
>
>
> Each Class will respond to the "help" class side method , so I figured
> start at the top with ProtoObject
>
> I am going to try a Visitor/Decorator pattern for every class in the system
>
> ProtoObject >>  help
>
> |help|
>
> help := MySoonToBeCodedVisitorClass visit: self.
>
> ^help
>
> Initially, just return the Class Comments, but with the
> MySoonToBeCodedVisitorClass later decorating the class comment and
> returning information from other sources too.
>
>
> BUT!!! I do not want to pollute ProtoObject if it is agains decorum.
>
> Thanks for your time
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200518/fd215dba/attachment.html>