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
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
