2016-08-25 8:47 GMT+02:00 Tudor Girba <tu...@tudorgirba.com>:
> Hi,
>
Hi Doru,
some questions and feedback ( I am sorry for my tone or if this sounds
negative, it isn't meant to be)
> Over the last coupe of years Stefan Reichhart and the rest of the GT team
> worked on an implementation of examples. The work is inspired from previous
> work done by Markus Gaelli and Adrian Kuhn.
>
> As one of the goals of GT is to offer a live programming environment,
Isn't this what we already have, a live programming environment, I think
for newcomers (and maybe others) this needs to make be more clear, how is
different, what gap are you trying to fill.
> one important issue is how to move from the static code to live objects as
> fast as possible.
Isn't code always "static" and aren't objects always "live", how do play
gtExamples any role in this?
> That is why we worked on this library as a solution to provide a link
> between the static code and live objects.
>
>From my understanding, I think this "link" between code an objects is the
real valuable new point. This is the great thing about gtExamples. link
from code (the example methods itself or methods refering a class
to an example object/instance that can be inspected (the raw object or an
object specific inspector pane).
This is what I would consider the real step forward. You see a method
refering to class TextModel and Nautilus or any other tool not only offers
a method to browse all Users of this class, but too, a dedicated
list of "example methods" where every example has a view for this example
instance that let the user show and interact (even for non-visual objects
through the "evaluater pane", or just see the code creating this
example.
We really miss examples, I often see questions on the mailing list
(especially about spect) that can be explained easily with an example. And
even worse, often the examples already exists, they just aren't as visible.
>
> Furthermore, this examples library also enables the definition of
> assertions on the examples, and this provides the possibility of rethinking
> the way we construct tests throughout our system. Tests are great as they
> help us create live objects and then to assert live properties.
This whole thing sounds as if Unit-Test were a good idea but not the way
that they are used today, I strongly disagree. I don't see this as a
"rethinking the way we construct tests", yes, we can
augment the current set of tests with addtional assertions on live objects,
but this is not a replacement.
"Tests are great as they help us create live objects" This is not my only
purpose for writing tests, often unit-tests cover methods and
"private-apis" not even considered to be used on live objects. You can not
(or I don't want to
) write tests only on "finished lived objects" sometimes we need tests for
initialiazation/private code or exception handling I don't see how we can
offer this only by using example instances (yes your "rethinking" sounds
like "this
is the better way to do tests").
> However, they do not allow us to leverage the objects we create, and this
> can be a tremendous resource for understanding systems.
>
> In our vision, examples should be everywhere and they should be explicitly
> linked to the static code they exemplify. That is why the library comes
> with an initial integration in existing tools (such as Nautilus, Spotter,
> Inspector).
>
> The current solution works well and it is the result of several rewrites.
> We think that the solution is complete in terms of features, but there are
> still several things to improve and iterate on. To this end, I kindly ask
> you to take a look at it while distinguishing between the concrete
> implementation choice (e.g., the current extensive use of pragmas) and the
> conceptual benefits of the approach.
>
> To ease the discussion, we put together a short documentation:
>
Everytime I see a gtExample method on a class I first think, shouldn't this
go to a Help or Doc or Exampels class instead. I don't know how others
thinks about this but this is my first impression.
For example, the example on your page:
FileSystem class >> #createFileOnDisk
<gtExample>
<description: 'Create a new file or override an existing file
with some contents. Open and close the stream safely'>
^ FileSystem workingDirectory / 'test.txt'
writeStreamDo: [ :stream | stream nextPutAll: self comment ];
yourself
Nice, now the user can see how to use FileSystem to create a file, open
*and* close the stream safely. But for me, this method does *not* belong
to the FileSystem class it just not make any sense to me, to have a method
(*in this class*) that opens and closes a stream. Even if this is just an
example, I would put it in a doc-page or a tutorial that can execute code.
But again , this is just my point of view.
I can not really explain it, having a example method on Morph or a widget
ui or a widget model class, that opens an example morph or widget in the
world, is for me something completly different and a valid example.
Having the same for the method above - is not, at least not as executable
code on the FileSystm class).
>
> http://gtoolkit.org/doc/Examples/examples.html
>
> That being said, you can get it with the full GToolkit in Pharo 6.0:
>
Is this based on the recent Pharo 6.0?
GTExamplesReleaseTests are failing for me
Where did you test this? I get some Object>>#name deprecation warnings when
browsing for examples refering a class, for example on
class FileSystem and menu entry "Browse Examples refering FileSystem"
(maybe a Pharo 5.0 version?)
The example on the examples.html side isn't actually in the image right?
The browsing examples of a package (context menu on nautilus package pane)
does not work or I don't understand why it does not find any examples at
all.
The World menu "Browse All Examples" does not contain the class FileSystem,
although FileSystem>>gtExampleZip is a gtExample, this is because
the example method is in an extension package, should all gtExample methods
be class extensions ? This is handled differently for different packages.
The code pane context menu of a sendersOf Message browser is broken (debug
menu).
>From the web-side:
"Furthermore, Nautilus, the World-Menu, all Rub-Text-Editors as well as
Spotter and Inspector provide access to retrieve, browse and navigate
examples from entities within the world"
I can not find it, not in inspector, Rub-Text-Editors, only in Nautilus.
And the menu entries are ... unfortunate (see screenshot), what you put in,
the whole source as menu label?
run "run the example and return its return-value"
debug "same run, but open debugger if the example fails"
returnValue "the return-value"
Executing run/debug/inspect returnValue does not seem to make any different
when called from nautilus. It always gives
an inspector on a dictionary holding the gtexample and its gtexampleresult
(is this a bug?)
Glossary:
"Example: an example is a tiny stub object representing a GT-Example. It
holds the references to its dependencies, subjects and many other entities.
"
What are "many other entities" this is a bit unclear
"After-method: the after-method is a method that is performed right after
the example."
After the example ? I thought an example is a "tiny stub *object*", how can
it run?
How it is run after I run an example for inspection, after I closed the
inspector?
>
> http://gtoolkit.org/#install
> (easiest is to download the ready made image for now)
>
> For those that are at ESUG, I will try to provide a short overview during
> the Show Us Your Project session from today.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Reasonable is what we are accustomed with."
>
>
>
