Smalltalk › Pharo › Pharo Smalltalk Developers

FileSystem. Possible FSReference rename

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Denis Kudriashov

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?

Stéphane Ducasse

Re: FileSystem. Possible FSReference rename

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?
>

Max Leske

Re: FileSystem. Possible FSReference rename

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?
>>
>
>

Denis Kudriashov

Re: FileSystem. Possible FSReference rename

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 <[hidden email]>

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?
>>
>
>

Stéphane Ducasse

Re: FileSystem. Possible FSReference rename

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

Sean P. DeNigris

Re: FileSystem. Possible FSReference rename

Administrator

In reply to this post by Denis Kudriashov

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

Cheers,
Sean

Camillo Bruni-3

Re: FileSystem. Possible FSReference rename

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

Denis Kudriashov

Re: FileSystem. Possible FSReference rename

In reply to this post by Sean P. DeNigris

2012/7/12 Sean P. DeNigris <[hidden email]>

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?