Le 15/9/16 à 22:16, Esteban A. Maringolo a écrit :
2016-09-15 17:09 GMT-03:00 Tudor Girba <tu...@tudorgirba.com>:
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




Reply via email to