torsten I'm confused. Did you use the <example> pragmas before? Because I was the one in favor to remove this ugly gt in front of gtExample Stef Le 25/3/15 17:32, Torsten Bergmann a écrit :
Hi Tudor,
However, I think there is significantly more value in examples that do return objects.
Yet again: no doubt that they may be of value. This is not the point. If they provide "more value" than methods that do not return an instance depends on what you want to achieve with them. But please accept the fact that they are NOT THE ONLY WAYof giving "examples" on system usage to others. There are in fact others as well. Regarding your script suggestion: Examples and script have in common is that they can be executed - but that does not automagically makes them the same. An example is CONCEPTUALLY not the same as a script. The purpose of creating a script is a different from the purpose of creating an example. A script is something I ran, an example is something that is explicitly provided for others to learn from it.
Until now, nobody is really using the <example> except the code that is packaged in GT
So you state that I'm nobody. Sad that my code does not count... :(
Is this really your argument that we now start counting and decide upon the number of methods that use this already? Do you really want the community to decide on that base in the future? Then we would had to write only ugly code because the ugly code outwighted the the number of clean code in the past when we forked from Squeak.
Again: this discussion is not about number of usage, it is about getting cleaner and about the correct naming.
The <example> tag as it was integrated from my side solves the problem of not relying on exampleXXX for tagging general code examples. You in parallel also used the same tag name for something that is more specific: an example method that returns an example instance/exemplar.
Nevertheless, please, let's focus on the release that comes in a few days. Especially because of the release in a few days I bring this topic up. When we keep it that way people will use it and we can hardly change it afterwards.Thats why I want a solution now and not defer this simple decision (it is nothing more) afterwards. we could remove the <example> pragma check from isExampleMethod
Why should we? You yourself wrote in the issue tracker that it is not good to only rely on selector names starting with exampleXXX.
The word example is based on previous research. Which say what? Academics is always right and in this context it now has to be like YOU stated? Please do not always get to far from the basic issue itself. We do not discuss how valuable this is - we know that already.
BTW: I have a degree in software technologies as well and support the idea of using congrete example objects. I agree with you in all the benefits, the underestimated power, etc. and would like to see Pharo move forward not only there. The most underestimated power is in its metaprogramming facilities.
The term "Example" is very general and in the Smalltalk contextalready and often usedto provide "example" methods. Some of them provide instances, others not. You talk only about the first subset: the examples who provide concrete instances. So we should name them accordingly: EXEMPLAR or EXAMPLEOBJECT in thecontext of OOP. I still stay with my proposal, we should stay consistent and name/mark things what they are: 1. general "examples" as <example> which solves the "not rely on method names" issue 2. and marking example method that are specifically returning an example instance with <exampleInstance> or <exemplar> or <sample> as Ben suggested
If it is a effort/time problem of changing the methods providing such example methods in the GT repo I offer to do this change.
As Pharo is not only YOURS and not only MINE I would like to see more opinions or proposals from others. ;)
Thanks T.