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