we could also use the "script:" annotation, and the system browser could show it at the class level (it already shows at the method level) nicolas On Thu, 2018-12-13 at 10:40 +0800, Ben Coman wrote:

A question was asked on discord... "I know how to start the lights out example, and feed my objects test data with the testing framework, but how does one start something like ChineseCheckers? How does one find the entry point? Is there a convention on naming a starting place?"

I remember having similar thoughts when starting in Pharo.

One convention I have seen is that amongst all the classes presumably prefixed "CC" one class would stand out being named for the application without the prefix. e.g. class "ChineseCheckers". That is only a narrow chance for a namespace conflict, the the risk still remains.

I suggested another path would have a package tag "Application" (i.e. "ChineseCheckers-Application") that contains a single class which has an #open method on the class-side. The tag "Application" sorts high up on the package-tags and is self- descriptive. But I've not seen that used before, so while I think its a good idea, its not really a convention. Conventions are only useful if they are broadly understood.

So I'm wondering what other things people do to draw attention to their application entry points.

cheers -ben -- Nicolas Anquetil RMod team -- Inria Lille

Hi Ben, On Wed, Dec 12, 2018 at 6:41 PM Ben Coman <btc@openinworld.com> wrote:

A question was asked on discord... "I know how to start the lights out example, and feed my objects test data with the testing framework, but how does one start something like ChineseCheckers? How does one find the entry point? Is there a convention on naming a starting place?"

I remember having similar thoughts when starting in Pharo.

One convention I have seen is that amongst all the classes presumably prefixed "CC" one class would stand out being named for the application without the prefix. e.g. class "ChineseCheckers". That is only a narrow chance for a namespace conflict, the the risk still remains.

I suggested another path would have a package tag "Application" (i.e. "ChineseCheckers-Application") that contains a single class which has an #open method on the class-side. The tag "Application" sorts high up on the package-tags and is self-descriptive. But I've not seen that used before, so while I think its a good idea, its not really a convention. Conventions are only useful if they are broadly understood.

So I'm wondering what other things people do to draw attention to their application entry points.

I use a combination of class-side categories (instance creation, examples, api, etc) and class comments. e.g. in the class comment for StackInterpreterSimulator in VMMaker you'll find: | vm | vm := StackInterpreterSimulator newWithOptions: #(). vm openOn: '/Users/eliot/Squeak/Squeak4.4/trunk44.image'. vm setBreakSelector: #&. vm openAsMorph; run But the above is hard to find. I buy Doru's examples approach. Usually interesting objects are used in some kind of context and there may be a flow that the above illustrates, instantiation => initialization => use. All this is possible with examples, and examples have a pragma to identify them to tools. So I would push the examples direction. I guess the kernel of this approach is to create a method that creates and uses some object, and that is labelled with a specific pragma identifying it as an example. It can then serve as both a test and an example to users.

cheers -ben

_,,,^..^,,,_ best, Eliot