Hi, Thanks for the message. There are several points under discussion.
I am not arguing now for introduction of GTExamples in the Pharo distribution. This is a discussion for the future. But, I would like to distinguish between the current implementation and the goal. I believe "Example-driven development" is an interesting possibility to raise awareness for Pharo especially if we double the technology with a practice or method that will be in line with the idea of live programming. It might sound far fetched, but I really believe we can deliver on that. GTExamples is a full first version (not a prototype). It certainly will not be the last. Regarding composition, in its simplest form, there is no composition, and for that you only need unary methods with <gtExample>. But, you do get the possibility of adding assertions and of specifying cleanups. So, relying on plain <gtExample> does not force you to use dependencies but you get extra advantages. Nevertheless, as I said before, composition is a point on which we want to work more. I believe it should be possible to use static analysis to recover example dependencies without the need of injecting arguments based on pragmas, but it is not yet clear how this would work. Cheers, Doru > On Dec 19, 2016, at 1:32 PM, Stephane Ducasse <[email protected]> wrote: > > Hi all > > In nautilus in Pharo 60 when you use > <sampleInstance> you can get an inspector on the object returned by the > method > > Example > > Die class >> d6 > <sampleInstance> > ^ self faces: 6 > > I started to use this pragma in all my libraries and I chose it to avoid > conflict with <example> and others. > > I can change another time to make everybody happy. But I would like to avoid > to have to change everything again because this is the second time. :) > So let me know. > > Now as I already said in the past, I will veto the integration of Examples > based on pragmas to compose them. > I do not want to need a special tools to get example working. But you know > all that. > > > Stef > > > > > > > > > > On Sun, Dec 18, 2016 at 10:49 PM, Tudor Girba <[email protected]> wrote: > Hi, > > As you might know, a while ago we created GTExamples, a framework that > supports both example-based live documentation and testing: > http://gtoolkit.org/doc/Examples/examples.html > > GTExamples was part of the GTInspector for a while, but as it evolved, we > pulled it out in a separate project. This separate project is not in Pharo > anymore but it is part of the full GToolkit configuration (Pharo only ships > the core of GToolkit). The idea of taking GTExamples out was to allow the > community to have a more elaborate discussion about the role of examples in > our environment. > > I have invited you to join that conversation, but it did not take off. I > understand that perhaps the topic does not look appealing at this moment. > > We will certainly continue to evolve GTExamples both on the semantics level > of the dependency constructs and on the integration with tools. Our goal is > to enable a new practice that I would like to call Example-Guilded > Development (or Example-Driven Development), and position Pharo to be the > only platform on which someone can do that. But, that is our goal, and does > not have to be the same with other people’s goal. > > Right now, GTExamples relies on the <gtExample> pragma to denote a method > that returns an object that exemplifies something. Executing this method as > an example should have no side-effects (either because the method itself does > not have a side-effect, or because the example method defines how the cleanup > should happen using the mechanism provided by GTExamples). > > This meaning is different from the meaning of the <example> pragma used > through Pharo. There are currently 55 places that use this pragma inside > Pharo and most of them come from FastTable. As things will progress and more > libraries might use GTExamples, the situation can become confusing. > > To make things less confusing in the future, I would like to define the > meaning of the <example> to denote a method that returns an object without > having side effects. Would you agree with this? > > If yes, I would suggest the name of the new pragma that would replace the > existing one to include “script” in the name. For example, <sampleScript>. > > What do you think? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > > -- www.tudorgirba.com www.feenk.com "Problem solving efficiency grows with the abstractness level of problem understanding."
