[Pharo-project] FileSystem. Possible FSReference rename
Hello, I hear many people does not like name FSReference in FileSystem package. Me too. Its not clear to me. But it is main object for end user. Maybe we can rename it to FSLocation? I frequently name variables that point to some file/dir like imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference. What do you think?
On Feb 21, 2011, at 2:54 PM, Denis Kudriashov wrote:
Hello,
I hear many people does not like name FSReference in FileSystem package. Me too. Its not clear to me. But it is main object for end user. Maybe we can rename it to FSLocation?
FSReference = FSSystem + FSPath So may be it could be renamed FSLocation.
I frequently name variables that point to some file/dir like imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference. What do you think?
Maybe I'm just retelling a story but there is already a class called FSLocator. If FSReference would be renamed to FSLocation I think FSLocator would have to be renamed too. Max On 23.02.2011, at 00:28, Stéphane Ducasse wrote:
On Feb 21, 2011, at 2:54 PM, Denis Kudriashov wrote:
Hello,
I hear many people does not like name FSReference in FileSystem package. Me too. Its not clear to me. But it is main object for end user. Maybe we can rename it to FSLocation?
FSReference = FSSystem + FSPath So may be it could be renamed FSLocation.
I frequently name variables that point to some file/dir like imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference. What do you think?
I think FSLocator and FSReference are same objects: FSReference = fileSystem + path FSLocator = "some origin object" + path. I think "some origin object" can be implemented as special FSRelativeFileSystem. And fileLocator became fileReference. 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? What is purpose of #resolve: and #resolve methods? Why so many classes (in FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem, FSResolver? 2011/2/24 Max Leske <maxleske@gmail.com>
Maybe I'm just retelling a story but there is already a class called FSLocator. If FSReference would be renamed to FSLocation I think FSLocator would have to be renamed too.
Max
On 23.02.2011, at 00:28, Stéphane Ducasse wrote:
On Feb 21, 2011, at 2:54 PM, Denis Kudriashov wrote:
Hello,
I hear many people does not like name FSReference in FileSystem package.
Me too. Its not clear to me. But it is main object for end user.
Maybe we can rename it to FSLocation?
FSReference = FSSystem + FSPath So may be it could be renamed FSLocation.
I frequently name variables that point to some file/dir like
imagesLocation, settingsLocation and others. Therefore it is natural to me have FSLocation instead FSReference.
What do you think?
Hi denis
I think FSLocator and FSReference are same objects: FSReference = fileSystem + path FSLocator = "some origin object" + path.
I think "some origin object" can be implemented as special FSRelativeFileSystem. And fileLocator became fileReference.
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? What is purpose of #resolve: and #resolve methods? Why so many classes (in FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem, FSResolver?
I do not know :) I'm trying to add comments to every single method so that we can get a better understanding of the system and change it. Stef
Denis Kudriashov wrote > > I think FSLocator and FSReference are same objects: > FSReference = fileSystem + path > FSLocator = "some origin object" + path. > > I think "some origin object" can be implemented as special > FSRelativeFileSystem. And fileLocator became fileReference. > > 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? > What is purpose of #resolve: and #resolve methods? Why so many classes (in > FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem, > FSResolver? >From Issue 6333: FileSystem refactoring "- cleaned up FileLocator / FileReference hierarchy - use FileLocators wherever possible" Cami, what do you think about Denis's point? Sean -- View this message in context: http://forum.world.st/FileSystem-Possible-FSReference-rename-tp3317375p4639654.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
2012/7/12 Sean P. DeNigris <sean@clipperadams.com>
Denis Kudriashov wrote
I think FSLocator and FSReference are same objects: FSReference = fileSystem + path FSLocator = "some origin object" + path.
I think "some origin object" can be implemented as special FSRelativeFileSystem. And fileLocator became fileReference.
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? What is purpose of #resolve: and #resolve methods? Why so many classes
(in
FileSystem) implement it: FSLocator, FSReferece, FSPath, FSFileSystem, FSResolver?
From Issue 6333: FileSystem refactoring "- cleaned up FileLocator / FileReference hierarchy - use FileLocators wherever possible"
Cami, what do you think about Denis's point?
Sean
Hello, Good you found this thread. I have no time to see deeper what happens with current FS state. But I think my questions not influence current design changes. So, I am very interesting what you thing about all of that?
participants (5)
-
Camillo Bruni -
Denis Kudriashov -
Max Leske -
Sean P. DeNigris -
Stéphane Ducasse