Hi,
> On Aug 20, 2016, at 10:12 PM, Nicolai Hess <[email protected]> wrote:
> 
> 
> 
> 2016-08-20 18:29 GMT+02:00 Tudor Girba <[email protected]>:
> Hi,
> 
> 
> > On Aug 20, 2016, at 1:29 AM, Nicolai Hess <[email protected]> wrote:
> >
> >
> >
> > 2016-08-20 0:26 GMT+02:00 Tudor Girba <[email protected]>:
> > Hi,
> >
> > > On Aug 20, 2016, at 12:22 AM, Nicolai Hess <[email protected]> wrote:
> > >
> > >
> > >
> > > 2016-08-20 0:02 GMT+02:00 Tudor Girba <[email protected]>:
> > > Hi,
> > >
> > > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <[email protected]> 
> > > > wrote:
> > > >
> > > >
> > > >
> > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <[email protected]>:
> > > > Hi,
> > > >
> > > > If you attache a certain action such as "result openInWorld” to a 
> > > > pragma such as <interactiveExample>, it implies that when I have a 
> > > > different resulting object that should be spawned with a different 
> > > > message (for example, a Roassal view should be opened with "result 
> > > > open"), I should use a different pragma. That will quickly lead to an 
> > > > explosion of pragmas.
> > > >
> > > > Cheers,
> > > > Doru
> > > >
> > > > I would not attach any action to a pragma, but instead let the 
> > > > different tools decide what to do. The pragma is just used to 
> > > > differentiate what the method execution returns:
> > > >
> > > > <example> or <exampleCode> - a code or script example - don't care 
> > > > about the returned object.  A tool like Nautilus just provides a way to 
> > > > execute the code ("play" - icon) nothing more.
> > > > <script> -  a code snippet for a more general use case (example or 
> > > > class initialization). A tool like Nautilus just provices a way to 
> > > > execute the code and for example, like it is now, show a growl 
> > > > notification with the result
> > > > <sample> or <sampleInstance> - code to create an instance. A tool like  
> > > > Nautilus can just provide a way to execute the code and open an 
> > > > inspector on the result. (The inspector itself can react differently for
> > > > a morph -> inspectors morph tab
> > > > a roassal view -> inspector tab for roassal view
> > > > ….
> > >
> > > The inspector has the instance and can react to it. But, how can Nautilus 
> > > know what to do without the instance? For that you would need static 
> > > information.
> > >
> > > by the pragma name ?
> > >
> > > <example> -> execute
> > > <sample> -> execute and inspect
> > > <script> -> execute and show a growl information with the returned value.
> >
> > As I understood the discussion, one issue was to associate an action that 
> > can be specific to an object,
> >
> > No, that wasn't what I meant.
> > The question was, do we need two pragmas <example> and <examplar>, if the 
> > <example> just opens a morph in the world instead of opening it in 
> > inspector.
> > And I would say "yes", because for some "examples" (look at the <example> 
> > tagged methods for FastTable) it makes more sense to have the morph in the
> > world instead of the inspector. But I don't want to associate this action 
> > #openInWorld to the pragma, instead, whoever writes the <example> method, 
> > should decide.
> > an <example> method for a morph should end with #openInWorld
> > an <example> method for a spec model should end with #openWithSpec
> > an <example> method for a roassal example should end with 
> > #whateverIsUsedToOpenItInAView.
> >
> 
> In this case, you will not be able to use the resulting object, and the new 
> energy around examples started from the need to utilize that ability The 
> other solution is to delegate the action to another pragma that can 
> complement the example one.
> 
> 
> what is " the new energy around examples” ?

This thread :).

I happen to believe that examples are an important ingredient in the future of 
Pharo, and I am just really happy that people want to invest attention and 
effort in it.

I also think that the examples problem is not a simple problem and finding the 
solution is not quite so straightforward.

There exists already a solution for examples inside the Pharo image. Stefan 
Reichhart and I worked on this for about 2 years now, and now we have a new 
version that is outside of the Pharo image. However, as it got in the Pharo 
image without much public discussion (this was a mistake on our side), we will 
now take it out to make sure that we can have that proper discussion. We are 
also trying our best to document it. I will follow up with more details in the 
next following days.

Doru


> Doru
> 
> > and the example given was a morph that people might want to interact with. 
> > This interaction would be achieved by sending openInWorld. But, maybe I 
> > misunderstood.
> >
> >
> >
> >
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > Doru
> > >
> > >
> > > > I am for <example> for the first case, <exampleCode> is good as well, 
> > > > but I like <example> more, and it is not uncommon to call some "code 
> > > > examples" just "examples"
> > > > <sample> for a method that creates "the interesting object", 
> > > > <sampleInstance> is fine as well.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > On Aug 19, 2016, at 10:32 AM, stepharo <[email protected]> wrote:
> > > > >
> > > > >
> > > > >
> > > > > Le 19/8/16 à 10:18, Tudor Girba a écrit :
> > > > >> Hi,
> > > > >>
> > > > >> I strongly believe that the interaction should not be hardcoded in 
> > > > >> the example pragma name. That is because you will want all sorts of 
> > > > >> interactions once you go beyond the surface. For example, a Roassal 
> > > > >> visualization, a Bloc element, and a Morph are all interesting from 
> > > > >> an interaction point of view, but there are different ways to open 
> > > > >> them (and having it polymorphic does not quite make sense).
> > > > >
> > > > > sorry but I cannot understand what you mean.
> > > > > You suggest to use example
> > > > > but not to have it polymorphic?
> > > > >>
> > > > >> Cheers,
> > > > >> Doru
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Aug 19, 2016, at 9:52 AM, stepharo <[email protected]> wrote:
> > > > >>>
> > > > >>> Let me know. I do not care about examplar or sample.
> > > > >>>
> > > > >>> Let us pick one that works well. I thought about prototype but this 
> > > > >>> is too close to prototype based language.
> > > > >>>
> > > > >>> So we could get
> > > > >>>
> > > > >>>    <interactiveExample>
> > > > >>>
> > > > >>>    <sample>/<instance>/
> > > > >>>
> > > > >>>
> > > > >>> Le 19/8/16 à 01:59, Ben Coman a écrit :
> > > > >>>> On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo
> > > > >>>> <[email protected]> wrote:
> > > > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <[email protected]>:
> > > > >>>>>> On 18/08/16 14:38, stepharo wrote:
> > > > >>>>>>> Hi
> > > > >>>>>>>
> > > > >>>>>>> In my projects I start to do the following:
> > > > >>>>>>>
> > > > >>>>>>> I create <examplar> class method that returns an prototypical 
> > > > >>>>>>> instance.
> > > > >>>>>> Nice. Excellent inititive. I'm not a native speaker, and 
> > > > >>>>>> <exemplar> does not
> > > > >>>>>> sound like the right name for this to me. That might be me being 
> > > > >>>>>> dutch.
> > > > >>>>>> Native speakers, is this the right name to use?
> > > > >>>>> Semantically it is correct, but for me, also maybe by not being a
> > > > >>>>> native English speaker, sounds weird.
> > > > >>>>>
> > > > >>>>> I'd use something like "sample". However I'll be fine with 
> > > > >>>>> whatever
> > > > >>>>> you choose. But I'd choose something that doesn't sound weird to
> > > > >>>>> native English readers, we already have some cases of that.
> > > > >>>>>
> > > > >>>>> Regards,
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> Esteban A. Maringolo
> > > > >>>>>
> > > > >>>> In the previous thread I argued against <exemplar> and for 
> > > > >>>> <sample>,
> > > > >>>> but I'm not so strong in my conviction to push it again :).  The
> > > > >>>> former is a little exotic, but is sufficient -- and perhaps its 
> > > > >>>> useful
> > > > >>>> <example> and <exemplar> sound similar with just a minor 
> > > > >>>> difference at
> > > > >>>> the end.
> > > > >>>>
> > > > >>>> P.S. In terms of discover-ability about this difference, a passing
> > > > >>>> thought is it would be nice for newcomers to be able to hover over 
> > > > >>>> a
> > > > >>>> code like a pragma and get a tool tip popup.
> > > > >>>>
> > > > >>>> cheers -ben
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >> --
> > > > >> www.tudorgirba.com
> > > > >> www.feenk.com
> > > > >>
> > > > >> "Next time you see your life passing by, say 'hi' and get to know 
> > > > >> her."
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > > www.tudorgirba.com
> > > > www.feenk.com
> > > >
> > > > "It's not how it is, it is how we see it."
> > > >
> > > >
> > > >
> > >
> > > --
> > > www.tudorgirba.com
> > > www.feenk.com
> > >
> > > "Obvious things are difficult to teach."
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Yesterday is a fact.
> >  Tomorrow is a possibility.
> >  Today is a challenge."
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "In a world where everything is moving ever faster,
> one might have better chances to win by moving slower."

--
www.tudorgirba.com
www.feenk.com

"When people care, great things can happen."





Reply via email to