- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Beta of Mooc webportal

by Gour

On Sat, 20 Aug 2016 15:24:05 +0200 stepharo <stepharo(a)free.fr> wrote: > I published a new version of the webportal (a packaged version of the > mooc) with the help of thibault. Now I'm about to test that all the > videos have indeed the correct subtitles. Yesterday and today I was going through W1 material. Congratulations for making people enthusisastic to learn and use Pharo!! > If you want to give me a hand or simply have a look > > http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html "Coding a Counter" video in W1.7 section [Redo] & [Lives] is cut short few minutes before the real end in comparison with the one at http://rmod-pharo-mooc.lille.inria.fr/MOOC/Videos/W1/ Another small gotcha is that embedded video player does not have option to click for a full-screen video, so it has to be selected via right-click menu. Sincerely, Gour -- Whatever action a great man performs, common men follow. And whatever standards he sets by exemplary acts, all the world pursues.

Aug. 20, 2016

Re: [Pharo-dev] <example>/<examplar>

by Tudor Girba

Hi, > On Aug 20, 2016, at 1:29 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > > > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)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(a)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(a)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(a)gmail.com> wrote: > > > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)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."

Aug. 20, 2016

Re: [Pharo-dev] Usability issue : the class/instance button in Pharo 5 gives poor feedback

by Oscar Nierstrasz

Well, as a user I want to see the current context as well. Thanks for pointing out that the methods and protocols on the class side are bold! Now that I know this I will watch for it; but it is not at all obvious. Following your point about buttons indicating what they would do, why not have the button say (C) when it would switch to the class view and (I) when it would switch back to the Instance view? Oscar > On Fri, Aug 19, 2016 at 02:15:06PM +0200, Oscar Nierstrasz wrote: >> >> Hi Folks, >> >> Does anyone else find this to be a problem? I can never tell whether I am on the class or the instance side as the button toggle is non-obvious. In fact, the (C) is more clearly visible on the instance side, which is counter intuitive. >> >> I would rather see the name of the button change between ?Instance? and ?Class? so I always know where I am. > > This would be imho confusing, because you would always see the opposite (it's a button, so the label should state what should happen when you click on it, not describing the current context). > > But there is also another visual clue which always makes it obvious (for me at least) on which side I am: on class side all methods are bold. > > Peter

Aug. 20, 2016

Re: [Pharo-dev] STON and (default) line endings

by stepharo

I got bitten by messy files recently and I have the impression that you should have in and out line ending settings (because may be you want to see Ston one way and output the other) And for the image I'm afraid by the amount of code it will break but it would be really good. May be migrating to Xtreams first should be the path. Stef Le 19/8/16 Ã 14:55, Sven Van Caekenberghe a Ã©crit : > Yes it would make much more sense to default to LF EOL (maybe not on Windows) in this century, but that is true for the whole image ... > >> On 19 Aug 2016, at 14:49, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> can we have a class-side configuration for STON line ending? >> >> Atm if I want to output with LF instead of CR (which is always), >> then I have to always do this >> >> String streamContents: [ :stream | >> (STON writer on: stream) >> prettyPrint: true; >> newLine: String lf; >> nextPut: data >> ]. >> >> I would be much happier if at least I could do this >> >> STON lineEnding: String lf >> >> (I could put the above in a StartupScript) >> >> And then just use regular STON toStringPretty: data. >> >> >> And I would be even happier if >> >> STON class>>lineEnding >> ^ String lf >> >> or >> >> STON class>>lineEnding >> ^ OSPlatform current isWindows >> ifTrue: [ String crlf ] >> ifFalse: [ String lf ] >> >> (Although always using LF by default might be preferable.) >> >> To summarize, it would be great if we could: >> >> * switch STON to LF _by default_ >> * allow users to easily switch to CR/CRLF if they need >> >> Thanks, >> Peter >> > >

Aug. 20, 2016

Beta of Mooc webportal

by stepharo

Hi I published a new version of the webportal (a packaged version of the mooc) with the help of thibault. Now I'm about to test that all the videos have indeed the correct subtitles. If you want to give me a hand or simply have a look http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html Once everything will be verified we will push it to the mooc web page and announce it. Stef

Aug. 20, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

>> 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-t… >> >> >> >> ----- >> 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. >> > >

Aug. 20, 2016

Re: [Pharo-dev] <example>/<examplar>

by stepharo

by the pragma name ? > > <example> -> execute > <sample> -> execute and inspect > <script> -> execute and show a growl information with the returned value. Exactly. :) This is the way I implemented it. Stef

Aug. 20, 2016

Re: [Pharo-dev] [squeak-dev] [Ann] Cuis now runs on Spur!

by Chris Muller

Cuis on Spur? Its like a powerful engine in a lightweight car. I can't imagine how blazing fast the UI must be. Easy Juan, you'll break the speed limits! :) On Fri, Aug 19, 2016 at 10:28 AM, <juanlists(a)jvuletich.org> wrote: > Hi Folks, > > I've successfully finished the Spur conversion of Cuis. I was able to merge > all required changes to Cuis compiler and make it work in both > ObjectMemories. Cuis is now offered in Spur and pre-Spur formats. And the > best part is that they share 100% of the source code. There is no forking! > > This means that there is no extra work in maintaining both flavors. So, we > are not leaving anyone behind. It also means that, at deployment, you might > chose between better performance and larger memory (with Spur) or smaller > footprint and SqueakJS compatibility (with pre-Spur). > > I've just updated our GitHub repo > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev . Included are > Cuis4.2-2906-spur.image and Cuis4.2-2906.image, and, as usual, the whole > update stream. I wrote a brief description of the Spur conversion at > Documentation/SpurConversion.md, in case you want to reproduce it, or apply > it to your own Cuis images. > > The images seem very stable. Please test them, load your code, and report > any issues. This work was enabled by Eliot Miranda and the OpenSmalltalk > team who develop Spur, VMMaker and the Spur bootstrap. Thank you folks! I > also used Squeak 5 as a reference implementation of Compiler and related > stuff. I also want to thank the greater Squeak community for it. > > Some cleanup is in order. The scaffolding I did for the conversion, > including dual Compilers is still in the image. I'll be cleaning it soon. > I'll also be able to pay a bit more attention to unrelated suggestions and > ongoing discussion at cuis-dev(a)cuis-smalltalk.org > > Enjoy! > > Cheers, > > Juan Vuletich > www.cuis-smalltalk.org > https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev > @JuanVuletich > >

Aug. 19, 2016

Re: [Pharo-dev] <example>/<examplar>

by Nicolai Hess

2016-08-20 0:26 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > 2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > > > > > > > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)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(a)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(a)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(a)gmail.com> wrote: > > > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)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." > > > > > >

Aug. 19, 2016

Re: [Pharo-dev] <example>/<examplar>

by Tudor Girba

Hi, > On Aug 20, 2016, at 12:22 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-08-20 0:02 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Aug 19, 2016, at 11:55 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-08-19 23:13 GMT+02:00 Tudor Girba <tudor(a)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(a)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(a)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(a)gmail.com> wrote: > > >>>>> 2016-08-18 17:30 GMT-03:00 Stephan Eggermont <stephan(a)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."

Aug. 19, 2016