Application entrypoints
Locked
 
|
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 |
|
|
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 |
|
|
Actually - kind of related, how does one know how to reset a framework like Seaside, or Zinc etc.
I’ve been thinking about proposing frameworks should have a #reset like pragma and then the system menu could find them and show the reset menu for all frameworks that provide it. I think applications could do a similar thing - have an #applicationStart pragma and then there could be an applications menu that listed them all in a convenient menu. Tim Sent from my iPhone > On 13 Dec 2018, at 08:38, nanqueti <[hidden email]> wrote: > > > 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 > > |
|
|
In reply to this post by Ben Coman
Hi Ben, On Wed, Dec 12, 2018 at 6:41 PM Ben Coman <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |