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