sven, I know. Still I think that I read a lot of code in a lot of languages and even more in Smalltalk and if I cannot find my way with anObject because it was too complex to write aStringOrReference then I should stop and this is what I'm doing. I stopped. I started to read fileMan and rio again not to integrate them but to have a look. In addition I'm not in the mood to get a sensitive abstraction dictated by 'oh we should not change it because it should run in squeak'. I feel the pain of Monticello without comments and I do not want that for files. I will not crawl to comment it even if people like the design because I have something else to do about my time. I also think that there are funny ideas. Why I cannot create an empty file or why a workingDirection isWorkingDirection is false and why workingDirection does not return a reference instead of a path......and a lot more. So first comment second test in black box (because most of the tests cannot be used to understand the public api and this is why I was trapped all the time) third refactor but it will not be me. Stef
Hi guys
I'm sorry but I stopped working on FS. I cannot guess what is private or not, what is the interface of this code. I spent my time guessing and guessing wrong. So I stop. Simple. In addition I will veto the integration of this code in this state to be added into pharo (sad I started to write an help but it is probably full of mistakes). I HATE undocumented code that tell me eveyr minutes that I'm a fucking idiot. Too bad I'm not smart enough. Now without decent comments (I mean more than a line in class comment when there is one) we cannot accept code. Sad but true. Good luck if you want to use it and improve it.
Stef
Stef,
Your quest for more comments is a good and a valid one, no question about it. And I don't want to defend FS, I only know it from Lukas' blog post and it seemed better than what we have now.
But the quality of a good design is certainly not just comments. It is perfectly possible to have code with lots of comments that is still bad. And if you take away all comments from a good design, it can still be a good design. Good abstractions, good names, separations of concerns, .. all those things that we all value are important. Using proper language idioms and conventions is another good idea. Many good programmers are a bit reluctant to write comments, and they usually value elegant code that speaks for itself.
I have certainly seen lots of really good code in the image that has little to no comments. And I have seen lots of comments that make me sick.
It also seems pretty hard for someone who is not the original author to write comments. And a prerequisite to writing comments is that you understand and like the system that you are commenting. If you are struggling with something, that does not seem like a good state of mind to improve the comments.
Sven
PS: the public/private distinction is a bit hard in Smalltalk, but the conventions seem to be method categories with 'private' in them, no ?