Smalltalk › Squeak › Squeak - Dev

Etiquette of adding a Class side *method category and method to ProtoObject

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Squeak - Dev mailing list

Etiquette of adding a Class side *method category and method to ProtoObject

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

codefrau

Re: Etiquette of adding a Class side *method category and method to ProtoObject

On Mon, May 18, 2020 at 12:43 PM gettimothy via Squeak-dev <[hidden email]> wrote:

Hi Foks,

TL;DR; is it a "BAD THING TO DO" to add a class side method to ProtoObject?

Yes.

Each Class will respond to the "help" class side method , so I figured start at the top with ProtoObject

The top is Object. ProtoObject is an implementation detail. We like to ignore it even exists.

I am going to try a Visitor/Decorator pattern for every class in the system

If this is for all classes, then the natural place to put it would be the instance side of Class, since all classes are (sub)instances of Class.

- Vanessa -

Chris Muller-3

Re: Etiquette of adding a Class side *method category and method to ProtoObject

In reply to this post by Squeak - Dev mailing list

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 <[hidden email]> 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

K K Subbu

Re: Etiquette of adding a Class side *method category and method to ProtoObject

In reply to this post by Squeak - Dev mailing list

On 19/05/20 1:13 am, gettimothy via Squeak-dev wrote:
> 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

There are already two "help" methods in Squeak:

HelpBrowser new openOn: aClass

This opens a window with class and method comments. It could do with
some improvements (i.e. strip out place holder comments, hot link text
to open class browser/hierarchy browser etc.). The help browser pops up
randomly on the screen. A better place would be just below the Help
button on the main docking bar. It will help draw attention to this
button. The ALT/CMD-? key is currently unused. It could be used to
invoke global or contextual (e.g. after a selection).

There is also the contextual help TextEditor>>explain. Currently, it
inserts help text in the editing pane. Instead it could use a balloon
help on hover.

Regards .. Subbu

Squeak - Dev mailing list

Re: Etiquette of adding a Class side *method category and method to ProtoObject

---- On Tue, 19 May 2020 07:02:58 -0400 K K Subbu <[hidden email]> wrote ----

There are already two "help" methods in Squeak:

Hi,

Now there are three if you want them:

MCHttpRepository
location: 'http://www.squeaksource.com/Doc'
user: 'tty'
password: ''

Doc help

'I am Squeak help that is solely CLI based.

The idiom is "command line" only, similar to Linux man or GNU info way of doing things.

Doc help

2020.05.19

Goals: display a class comment. Update a class comment, append to a class comment. prepend to a classs comment.

Problem statement:

There is plenty of Help available for Squeak, however, it is NOT in Squeak.
Empirically people do not like to write help as evidenced by Class comments or the HelpBrowser.

The problems therefore are "ease of creation", "aggregation", "display" and "storage".

Current thinking is to utilize Visitor and Decorator (?) Builder (?) patterns to build a me.

I will contain Doclets, which are things that wrap a particular kind of help: Use cases, examples, terse guide, mail discussionts, comments.

I will be building in comments , similar to StackOverFlow with ratings, date, etc.

I would love this thing to grow with Squeak over time.

all the best.