Pharo-dev

By thread

pharo-dev@lists.pharo.org

August 2016

766 messages

Re: [Pharo-dev] About PythonDocTest for Pharo

by Denis Kudriashov

2016-08-18 13:32 GMT+02:00 stepharo <stepharo(a)free.fr>: > withExtension: aString > > "Returns a new file reference with a different file extension" Does this comment is really needed? I only see extra word "different". And rest is same as method name. IMHO we should rename method to "withDifferentExtension:" and remove comment.

Aug. 18, 2016

Re: [Pharo-dev] About PythonDocTest for Pharo

by Denis Kudriashov

Hi. 2016-08-18 9:34 GMT+02:00 stepharo <stepharo(a)free.fr>: > withExtension: aString > > "Returns a new file reference with a different file extension" > > <exp: '/tmp/file.txt' asFileReference withExtension: 'log' > > value: '/tmp/file.log' asFileReference > > > ^ self withPath: (self path withExtension: aString) > > > So let me know what you think. > - tell me that we have already test unit (yes the ones I wrote too) > => they do not have the same purpose > I am sorry, but I want to said it: we have tests. Why tests are not for same purpose? (I would say they include it). As Tudor said: "they are way too disconnected from the code" And this needs to be solved. We already have nice feature in Nautilus: it shows "test icon" on covered methods. We could extends this idea to simplify test visibility. Proposed solution is much simpler. But how much it is practical? How many code could use it? For simple cases like String methods is super nice. But could you imaging it for Seaside code? or Morphic?

Aug. 18, 2016

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

by Esteban A. Maringolo

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

Aug. 18, 2016

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

by Nicolai Hess

2016-08-18 22:45 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)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. > > > >

Aug. 18, 2016

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

by Tudor Girba

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-Inspec… Cheers, Doru > On Aug 18, 2016, at 10:45 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)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."

Aug. 18, 2016

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

by Denis Kudriashov

2016-08-18 19:50 GMT+02:00 stepharo <stepharo(a)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.

Aug. 18, 2016

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

by Stephan Eggermont

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

Aug. 18, 2016

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

by stepharo

A little blog post to explain https://wordpress.com/post/pharoweekly.wordpress.com/1190 Stef

Aug. 18, 2016

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

by stepharo

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

Aug. 18, 2016

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

by stepharo

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

Aug. 18, 2016

← Newer
1
...
37
38
39
40
41
42
43
...
77
Older →

Jump to page: