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 WAY of 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 context already and often used to 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 the context 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

��