Michael Rueger wrote:
Damien Cassou wrote:
Rio is a *must* have for Pharo.
I politely disagree.
There isn't anything in Rio that isn't already or could easily be
added to URIs.
I'm also not a big fan (to say the least) of adding "convenience"
methods (like the zip stuff in Rio).
IMHO convenience is the death of good design.
Michael
The basic way that RioKernel works is layered upon the VM primitives.
The guts of the implementation is built upon one method... #select:
selectBlock which calls #startAt: rioOrString recursively: beRecursive
select: selectBlock into: results
I was quite pleased with the way this worked out being quite elegant,
and so if you want to add this to URI's it would be better to implement
URIs on top of Rio or RioKernel, than FileDirectory.
The zip stuff in rio is not "convenience" methods, it aims to
transparently implement an alternate file system, a zip file. I havent
got around to doing remote ftp file systems, but that should be
achievable using the same approach.
The gzip mode implements an alternate file type, piping to and from
compressed streams, again transparently.
The ultimate aim here, is to be able to hand a rio as a parameter into a
tool, and that tool should be able to read and write to the file
represented by the rio, irrespective of whether that rio represents a
remote file, a gziped file or a file within a zip file. Its basically
polymorphism in action, and I would like to think that that is good design.
Keith
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
