[Pharo-project] FileSystem. Possible FSReference rename

Camillo Bruni camillobruni at gmail.com
Thu Jul 12 08:28:35 EDT 2012


Hi sean / denis, 

see my comments below...

On 2012-07-12, at 14:10, Sean P. DeNigris wrote:
> Denis Kudriashov wrote
>> 
>> I think FSLocator and FSReference are same objects:
>> FSReference = fileSystem + path
>> FSLocator = "some origin object" + path.

indeed they are way to similar ;), I doubted myself a couple of times already
whether they are really needed or not :) and I do not particularly like the 
implementation :/

>> I think "some origin object" can be implemented as special
>> FSRelativeFileSystem. And fileLocator became fileReference.

Indeed a relative filesystem is something I need (or better a relative store..)
This is specially nice if you want to start stacking filesystems into each other.
I will explicitly need that for the new internal Pharo2.0 fileystem...

>> Now in "FSLocator vmDirectory" "some origin object"  is symbol. And
>> FileLocator>>resolve method perform some complex stuff through FSResolver
>> hierarchy logic.
>> 
>> What is purpose of FSResolver hierarchy?

You need at least on per Platform (resolving home / preferences / documents...)
That will leave you with already 3 different implementations. But actually it
might make sense to put these methods (as extensions?) on the specific stores!

>> What is purpose of #resolve: and #resolve methods? Why so many classes (in
>> FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem,
>> FSResolver?

I will think about it a bit more. I don't have real refactoring plans for FileSystem
anymore, so if someone comes up with a nice solution I am glad to adapt it and
put it in 2.0 :)

best
cami



More information about the Pharo-dev mailing list