On 13 December 2012 14:52, Colin Putney colin@wiresong.com wrote:
On Thu, Dec 13, 2012 at 6:34 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes, and the inclusion of Colin's FileSystem into Squeak is planned for 4.5 as I understand the minutes of the board meetings.
Well, it was proposed, and a few board members were receptive to the idea, but that's not a final decision. Just to be clear, the Board's job is to manage the administrivia of community infrastructure, like servers and mailing lists. Setting the development agenda falls the community at large.
I think the best way to introduce Filesystem in the base image would be to include just the core packages (FS-Core, FS-Disk, FS-Tests-Core and FS-Tests-Disk), and leave the others as optional, loadable additions. That core would be sufficient to cover all the functionality provided by FileDirectory, and parts of the system that deal with files can be gradually migrated over.
I wrote a couple of paragraphs on why it wouldn't make sense to have an implementation FileDirectory as a layer on top of Filesystem, but then I came to the conclusion that it might not be a bad idea after all. The devil is in the details, and we ought to look into the details. Either way, the current implementation of FileDirectory should eventually be available as a loadable package, so that we can still build images with legacy code that depends on it.
Also, I wanted to point out that FS-AnsiStreams is basically obsolete. I wrote it because FileStream and friends couldn't be adapted to work with non-disk filesystems, and I wanted to have a single, uniform interface for reading and writing files, regardless of the type of filesystem that contained them. But then I discovered that Xtreams already does a way better job of that than anything I could have written. There might be some value in FS-AnsiStreams as an ANSI-compliant portability interface, but AFAICT, no dialect supports this part of the ANSI standard correctly anyway, so it wouldn't be much use.
And that's pretty much most of the reason for Martin & Mark writing Xtreams - noone implemented streams in quite the same way (and there were things that were just wrong in the spec, but can't recall the details).
frank