Hi In my projects I start to do the following: I create <examplar> class method that returns an prototypical instance. I use such methods in my tests as fixture. Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press on them I get an inspector on them. This way I get the same behavior than with default <example> methods that open an widget, image.... If we agree on that - I can take all the <example> and turn them if necessary into examplar. - extend Nautilus to send an inspect to the result of examplar tagged method. I think that we can achieve a lot in terms of discovery with such simple changes. Stef PS: I reread the old thread and I think that this is a reasonable approach that makes the pro instances (like me) and the pro examples showing some things (like me) happy.
Hi Why not use <example> pragma in the way you propose for <examplar>? Why we need two? 2016-08-18 14:38 GMT+02:00 stepharo <stepharo@free.fr>:
Hi
In my projects I start to do the following:
I create <examplar> class method that returns an prototypical instance.
I use such methods in my tests as fixture.
Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press
on them I get an inspector on them.
This way I get the same behavior than with default <example> methods that open an widget, image....
If we agree on that
- I can take all the <example> and turn them if necessary into examplar.
- extend Nautilus to send an inspect to the result of examplar tagged method.
I think that we can achieve a lot in terms of discovery with such simple changes.
Stef
PS: I reread the old thread and I think that this is a reasonable approach that makes
the pro instances (like me) and the pro examples showing some things (like me) happy.
example is meant to be something executable from the browser (and with a visible result) while âexemplarâ will just provide a prototype. this is old discussion, sigh... Esteban
On 18 Aug 2016, at 16:25, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi
Why not use <example> pragma in the way you propose for <examplar>? Why we need two?
2016-08-18 14:38 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>: Hi
In my projects I start to do the following:
I create <examplar> class method that returns an prototypical instance.
I use such methods in my tests as fixture.
Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press
on them I get an inspector on them.
This way I get the same behavior than with default <example> methods that open an widget, image....
If we agree on that
- I can take all the <example> and turn them if necessary into examplar.
- extend Nautilus to send an inspect to the result of examplar tagged method.
I think that we can achieve a lot in terms of discovery with such simple changes.
Stef
PS: I reread the old thread and I think that this is a reasonable approach that makes
the pro instances (like me) and the pro examples showing some things (like me) happy.
Hi
Why not use <example> pragma in the way you propose for <examplar>? Why we need two?
Apparently from the old discussion, people like <example> to prompt and open the example when this is something visual. This is ok for me. In my proposal we can get the best of both worlds. - instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening. Stef
2016-08-18 14:38 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:
Hi
In my projects I start to do the following:
I create <examplar> class method that returns an prototypical instance.
I use such methods in my tests as fixture.
Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press
on them I get an inspector on them.
This way I get the same behavior than with default <example> methods that open an widget, image....
If we agree on that
- I can take all the <example> and turn them if necessary into examplar.
- extend Nautilus to send an inspect to the result of examplar tagged method.
I think that we can achieve a lot in terms of discovery with such simple changes.
Stef
PS: I reread the old thread and I think that this is a reasonable approach that makes
the pro instances (like me) and the pro examples showing some things (like me) happy.
2016-08-18 19:50 GMT+02:00 stepharo <stepharo@free.fr>:
Hi
Why not use <example> pragma in the way you propose for <examplar>? Why we need two?
Apparently from the old discussion, people like <example> to prompt and open the example when this is something visual. This is ok for me.
Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?) I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss.
In my proposal we can get the best of both worlds. - instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening.
Hi, I am happy to see the concept of an example method catching attention again. As explained before, the GTExample was already present in the Pharo image, but it was introduced more as a helper for testing GT extensions. Now, I just created an issue for removing GTExamples from the GT-Inspector package and from the main Pharo image: https://pharo.fogbugz.com/f/cases/18965/Remove-GTExample-from-the-GT-Inspect... Cheers, Doru
On Aug 18, 2016, at 10:45 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-08-18 19:50 GMT+02:00 stepharo <stepharo@free.fr>:
Hi
Why not use <example> pragma in the way you propose for <examplar>? Why we need two?
Apparently from the old discussion, people like <example> to prompt and open the example when this is something visual. This is ok for me.
Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?)
I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss.
In my proposal we can get the best of both worlds. - instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening.
-- www.tudorgirba.com www.feenk.com "Every thing should have the right to be different."
2016-08-18 22:45 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
2016-08-18 19:50 GMT+02:00 stepharo <stepharo@free.fr>:
Hi
Why not use <example> pragma in the way you propose for <examplar>? Why we need two?
Apparently from the old discussion, people like <example> to prompt and open the example when this is something visual. This is ok for me.
Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?)
I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss.
some <example> methods don't just show a morph that you want to inspect, but a Morph that you want to interact with. And not all Morphs render well in the inspectors Morph tab. <script> - execute some code, don't care about the return value <example> - create an (UI/Morph)-example you can interact with <exemplar> - create an example instance. I like all three of them and can see a value for every single one.
In my proposal we can get the best of both worlds.
- instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening.
Ok, let's distinguish them. Scripts are scripts (maybe <script> is better name than <example>?)
I thought that we don't need two options because in practice <example> only opens morph or inspector. And for morphs we already have morph tab in inspector. So morph examples could be easily converted to <examplar> without any loss.
@Denis there was a long debate a while ago and I do not want to rediscuss it. Personnally I have no preconceived points on naming. I want just a way to get instance and that people are happy and that the solution stay ridiculously simple.
some <example> methods don't just show a morph that you want to inspect, but a Morph that you want to interact with. And not all Morphs render well in the inspectors Morph tab.
<script> - execute some code, don't care about the return value <example> - create an (UI/Morph)-example you can interact with <exemplar> - create an example instance. I like all three of them and can see a value for every single one.
@Nicolai Me too. So we are in sync :) I wonder where we can document that. I would have changed <example> into <popupExample>/<interactiveExample> And it is not a dogma for me. Just to make sure that we move on. Because I got student changing my "<examplar>" not tagged method to add an inspect call, not fun when running my tests :) but it was clear that they wanted to have an inspector to tweak the object.
In my proposal we can get the best of both worlds. - instance to use in tests - instance to learn and tweak with GTInspector - examples that we can see opening.
Hi all I implemented the <examplar> to behave as suggested by torsten and it is available in less than 5 min (I loved it). An example is JUST a class method returning an instance. CTGrid class >> grid22 <examplar> "self grid22" | grid1 | grid1 := self new: 2. grid1 atRow: 1 atColumn: 1 put: 1. grid1 atRow: 1 atColumn: 2 put: 3. grid1 atRow: 2 atColumn: 1 put: 2. grid1 atRow: 2 atColumn: 2 put: 4. ^ grid1 You can use this method as any class method in the past. NOTHING new!! So in particular your test can use it to build a fixture (yes reuse). You can use this method in several test cases (yes reuse). Now nautilus supports nicely <examplar> methods: you can execute them and get a cool GTInspector open on them. So this is similar to the method exampleSomething from Nautilus point of view. And now people can use example to create/open/... their lovely examples (that may not return instances). And we get examplar methods that must return an instance but can behave as example from Nautilus perspective. https://pharo.fogbugz.com/f/cases/18964/support-examplar If you want to try you can load the CTGrid packages ScriptLoader new unloadPackageNamed: 'Collections-Grid'. ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'. "Because there were not good and will be removed from the image" Gofer it url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main'; configurationOf: 'Grid'; loadStable Click on class side of CTGrid and press the triangle and yes you get an inspector on this instance. Stef Le 18/8/16 à 14:38, stepharo a écrit :
Hi
In my projects I start to do the following:
I create <examplar> class method that returns an prototypical instance.
I use such methods in my tests as fixture.
Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press
on them I get an inspector on them.
This way I get the same behavior than with default <example> methods that open an widget, image....
If we agree on that
- I can take all the <example> and turn them if necessary into examplar.
- extend Nautilus to send an inspect to the result of examplar tagged method.
I think that we can achieve a lot in terms of discovery with such simple changes.
Stef
PS: I reread the old thread and I think that this is a reasonable approach that makes
the pro instances (like me) and the pro examples showing some things (like me) happy.
Le 18/8/16 à 21:31, stepharo a écrit :
Hi all
I implemented the <examplar> to behave as suggested by torsten and it is available in less than 5 min (I loved it). An example is JUST a class method returning an instance. examplar is JUST... :)
CTGrid class >> grid22 <examplar> "self grid22" | grid1 | grid1 := self new: 2. grid1 atRow: 1 atColumn: 1 put: 1. grid1 atRow: 1 atColumn: 2 put: 3. grid1 atRow: 2 atColumn: 1 put: 2. grid1 atRow: 2 atColumn: 2 put: 4. ^ grid1
You can use this method as any class method in the past. NOTHING new!! So in particular your test can use it to build a fixture (yes reuse). You can use this method in several test cases (yes reuse).
Now nautilus supports nicely <examplar> methods: you can execute them and get a cool GTInspector open on them. So this is similar to the method exampleSomething from Nautilus point of view. And now people can use example to create/open/... their lovely examples (that may not return instances). And we get examplar methods that must return an instance but can behave as example from Nautilus perspective.
https://pharo.fogbugz.com/f/cases/18964/support-examplar
If you want to try you can load the CTGrid packages
ScriptLoader new unloadPackageNamed: 'Collections-Grid'. ScriptLoader new unloadPackageNamed: 'Collections-Grid-Tests'. "Because there were not good and will be removed from the image" Gofer it url: 'http://smalltalkhub.com/mc/StephaneDucasse/Containers/main'; configurationOf: 'Grid'; loadStable
Click on class side of CTGrid and press the triangle and yes you get an inspector on this instance.
Stef
Le 18/8/16 à 14:38, stepharo a écrit :
Hi
In my projects I start to do the following:
I create <examplar> class method that returns an prototypical instance.
I use such methods in my tests as fixture.
Then I would like to have nautilus presenting to me the <examplar> with a little triangle and when I press
on them I get an inspector on them.
This way I get the same behavior than with default <example> methods that open an widget, image....
If we agree on that
- I can take all the <example> and turn them if necessary into examplar.
- extend Nautilus to send an inspect to the result of examplar tagged method.
I think that we can achieve a lot in terms of discovery with such simple changes.
Stef
PS: I reread the old thread and I think that this is a reasonable approach that makes
the pro instances (like me) and the pro examples showing some things (like me) happy.
A little blog post to explain https://wordpress.com/post/pharoweekly.wordpress.com/1190 Stef
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? Stephan
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
On Fri, Aug 19, 2016 at 5:09 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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
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). Cheers, Doru
On Aug 19, 2016, at 9:52 AM, stepharo <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
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
On Aug 19, 2016, at 10:32 AM, stepharo <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
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 .... 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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. 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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.
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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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, 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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.
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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
Hi,
On Aug 20, 2016, at 1:29 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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. 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
2016-08-20 18:29 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 20, 2016, at 1:29 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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" ?
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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl
:
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."
Hi,
On Aug 20, 2016, at 10:12 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 18:29 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 1:29 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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 <stepharo@free.fr> 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 <stepharo@free.fr> 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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan@stack.nl>:
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."
2016-08-20 22:24 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
On Aug 20, 2016, at 10:12 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 18:29 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 1:29 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: Hi,
On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>: 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.
good! ( I don't know much about the "solution for example inside teh Pharo image", I am not sure they are working as expected, and I am not sure I understand how they are supposed to work :-)
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 <stepharo@free.fr> 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 <stepharo@free.fr>
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 <emaringolo@gmail.com> wrote:
2016-08-18 17:30 GMT-03:00 Stephan Eggermont <
stephan@stack.nl>:
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."
Tudor Girba-2 wrote
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.
Isn't that what we've settled on? That is, <sampleInstance> for when you need the result? It seems that all bases are covered if those methods return an instance and the browser button takes that instance and opens an inspector, no? ----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4912083.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi sean this is exactly with <sampleInstance> but this is not exactly the solution doru envision. But I think that sampleInstance is letting people build extra tools and also let people use the sample method in their test and others. Stef Le 21/8/16 à 02:01, Sean P. DeNigris a écrit :
Tudor Girba-2 wrote
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. Isn't that what we've settled on? That is, <sampleInstance> for when you need the result? It seems that all bases are covered if those methods return an instance and the browser button takes that instance and opens an inspector, no?
----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4912083.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I will probably sound stupid but here I go. I am no fan of Pragmas. I feel that their syntax is weird and unnecessary and what they do can be easily achieved with a secondary class that provides this meta data. In case of examples it would have been possible to have examples in a separate package together with a class that provides the additional info the IDE needs to trigger the right tools. On the other hand I was neither a fan of using example as part of a method name. Saying that instancePrototype sounds a lot more clear than examplar. On Mon, 22 Aug 2016 at 08:39, stepharo <stepharo@free.fr> wrote:
Hi sean
this is exactly with <sampleInstance> but this is not exactly the solution doru envision.
But I think that sampleInstance is letting people build extra tools and also let people use the sample method
in their test and others.
Stef
Le 21/8/16 à 02:01, Sean P. DeNigris a écrit :
Tudor Girba-2 wrote
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. Isn't that what we've settled on? That is, <sampleInstance> for when you need the result? It seems that all bases are covered if those methods return an instance and the browser button takes that instance and opens an inspector, no?
----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4912083.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
stepharo wrote
Let me know. I do not care about examplar or sample.
In the original thread [1]: - The most popular naming option was for some combination of exampleInstance, exampleCode, sampleInstance, and sampleCode because they are both natural-sounding-to-native-ears and explicit. - There was a small (Ben and I) consensus leaning specifically toward <exampleCode> together with <sampleInstance> - Exemplar (note it's not spelled exAmplar) is a bit obscure English - There were some more exotic parameterized varieties discussed, but maybe it's best to save those for a future evolution [1] http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-td... ----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 19 Aug 2016, at 17:35, Sean P. DeNigris <sean@clipperadams.com> wrote:
stepharo wrote
Let me know. I do not care about examplar or sample.
In the original thread [1]: - The most popular naming option was for some combination of exampleInstance, exampleCode, sampleInstance, and sampleCode because they are both natural-sounding-to-native-ears and explicit. - There was a small (Ben and I) consensus leaning specifically toward <exampleCode> together with <sampleInstance>
That makes a lot of sense, so +1 And UI stuff would then be a case of <exampleCode> right, as side effect ?
- Exemplar (note it's not spelled exAmplar) is a bit obscure English - There were some more exotic parameterized varieties discussed, but maybe it's best to save those for a future evolution
[1] http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-td...
----- Cheers, Sean -- View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>> stepharo wrote >>> Let me know. I do not care about examplar or sample. >> In the original thread [1]: >> - The most popular naming option was for some combination of >> exampleInstance, exampleCode, sampleInstance, and sampleCode because they >> are both natural-sounding-to-native-ears and explicit. >> - There was a small (Ben and I) consensus leaning specifically toward >> <exampleCode> together with <sampleInstance> > That makes a lot of sense, so +1 > > And UI stuff would then be a case of <exampleCode> right, as side effect ? Yes So <sampleInstance> instead of <examplar> Do we agree? and I just do update the slice. Stef > >> - Exemplar (note it's not spelled exAmplar) is a bit obscure English >> - There were some more exotic parameterized varieties discussed, but maybe >> it's best to save those for a future evolution >> >> [1] >> http://forum.world.st/lt-example-gt-pragmas-and-example-methods-use-cases-td4833428.html >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/example-examplar-tp4911728p4911947.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >
participants (11)
-
Ben Coman -
Denis Kudriashov -
Dimitris Chloupis -
Esteban A. Maringolo -
Esteban Lorenzano -
Nicolai Hess -
Sean P. DeNigris -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Tudor Girba