Stef and Max, I was just about to pull together the changes that I'd made to Filesystem for the port to GemStone and was just about to bag the whole effort until Max stepped in ... So, Max I'll share a little bit here...then when and if you pick things up again, let me know and I'll try work with you to integrate my changes. The port was based on Filesystem-lr.83 and my mcz files are located in: http://seaside.gemstone.com/ss/fs I restructured things into three packages: Filesystem FilesystemPharo FilesystemGemStone Besides pushing platform-specific code around I added a FSReadWriteStream class so I would have a Filesystem-based read/write stream that was independent of Squeak/Pharo... I seem to recall that I had some notions about more restructuring that I thought might be useful but I'd have to get my head back into the code again to refresh my memory ... Dale On 02/04/2011 09:09 AM, Max Leske wrote:

I'll try to give it a shot in the next two or three months if that's any comfort.

Max

On 04.02.2011, at 17:36, Stéphane Ducasse wrote:

...

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

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 ?

...

Maybe the code base is indeed not good enough, not finished (yet).

I think that it is good (may be a bit over engineered -- not sure that having visitors is really necessary) but I think that it is good except that it frustates me immensely that I cannot understand it fast. So I stopped.

Maybe some important abstractions and even functionalities are (still) missing.

A couple of lines of comments (like a class comment stating the purpose), the usual Smalltalk conventions and some unit tests should be the minimum indeed.

Anyway, things are improving a lot in Pharo, so that is good.

It is just that it is an enormeous amount of work to write open source code, publish it, support and document it, you know that too.

Yes

Sven