Le 15/9/16 à 22:16, Esteban A. Maringolo a écrit :
2016-09-15 17:09 GMT-03:00 Tudor Girba <[email protected]>:
However, one thing to keep in mind is that one reason why these solutions exist
is because they assume no UI environment. Thus, the only thing they have is
text and the solution is built around it.
In Pharo, we can think of concatenating information in the environment. If we
have a casual connection between examples and the code they exemplify, the
interface can provide all this information at the same time. The advantage here
is that the syntax remains simple.
+1
I wouldn't like that syntax, nor PharoDoc (a la JavaDoc), nor anything
"polluting" the code that way.
It is not polution, it is documentation.
Apparently you are not the guy that got the HUGE pain to write the
method comment and the chapter about FileSystem.
I'm probably too stupid. To understand what each method was doing I had
to TRY and ERROR.
I recently try to understand certain behavior of the Date package and
same syndrome. Without an example it is impossible to
get **exactly** what the method is doing.
So that you do not use it in your code is your style and life. Now Pharo
must improve from that perspective.
I do not want to read five methods with different context to understand
that basename includes the extension
'/foo/gloops.taz' asFileReference basename is 'gloops.taz
and that name does not.
Sorry but as one of the leader of Pharo if I do not have such exigence
and vision for our system then I should go do something else.
Stef
The comment or examples can be attributes of the method itself, just
like the class comment are today.
Regards!
Esteban A. Maringolo
