Stéphane Ducasse wrote:
Hello keith
I read the NullPattern and I read the code of Rio. I saw that you use NullPattern and not nil eating I agree with you that killing FileDirectory is a goal in itself. :)
I read the wiki page on rio, browse the code and read the fileman/rio comparison. I like rio (I was already convinced). I like the select:
=== I like the idea that we could have an internal representation for the file and platform related code would map that to the given OS. While I was discussing with mike, he told me that in Sophie they used consistently URI and got really platform independent code.
=== Do you think that URI could be introduced in Rio? I have no idea what URI is. And I have some questions
=== I like that we can have a sequential or cascading mode now I do not really see the point of this setModeToRenaming... is it in the Rio version? Yes. Then I do not understand why setModeToRenaming: true leads to changing file to disc: this seems to me obscure. " Introducing Modes - 'Renaming' Mode When a Rio is #setModeToRenaming, all of the above fileName and path manipulations are simultaneously actualized on disk.
??? It was a feature of the ruby version of rio, that renaming a rio renamed the file on disk. Once in renaming mode the filename can be changed using any of the specialist accessors, e.g #ext: #version:
When a mode is set using 'cascading' style, (e.g. #setModeToRenaming) the mode flag is set on the given instance as you would expect. In contrast, when a mode is set in sequential style, a new instance is created, making the mode setting temporary for the remainer of that 'sequential sentence'. This convention applies to all modes. e.g.
* cascading: (myFile setModeToRenaming; yourself) base:'temp'. â the renamng mode flag of myFile is set. * sequential: myFile rename base: 'temp'. â myFile itself is untouched, the renaming mode flag is set in the myFile copy that performs #base: " === + do you think that , would not be better than + for path concatenation? It would fit better the concatenation in Smalltalk Rio currently uses #/ and #+ for path concatenation. #+ is specifically intended for adding a suffix/extension to a pathname.
We have already got #, defined as "string concatenation", this is one of the methods which allows Rios to be used in the same place as a string would be used.
=== ifAbsent I found strange that
ifAbsent ^ self exists not ifTrue: [ self ] ifFalse: [ Null default ] => ifAbsent ^ self exists ifFalse: [ Null default ] ifTrue: [ self ] So did I! Fixed in latest. === I was thinking that it would be nice to have a group of pharoer going over rio and - giving feedback sure - formatting the code If you have time write a decent code formatter, ST/X has two, unfortunately this is why I am lazy.
- writing the tests (I could not find them)
Tests are in squeaksource/Rio The more the merrier.
Then in a second iteration integrating rio in the system and deprecating FileDirectory and others.
=== I was wondering why we could not have 'myFile.dat' asRio gzip compress => 'myFile.dat' asGzipCompress I saw that you have adaptor now with class extensions we could have new methods added for new adaptors. Especially since you have toyr setModeToXXX methods
I think that's the plan.
Stef _______________
Keith