FileSystem inconsistency

Hello,

I was writing a small utility using FileSystem. I had never used
FileSystem before. So I am browsing the code trying to learn where to
start and how to use it.

It took me a little while to learn to do something like:
fs := FileSystem store: (DiskStore activeClass createDefault).

It would be nice if there were an instance creation method like
FileSystem createDefault   which would do the above.

My utility was renaming some files. Once I had acquired a
FileSystemDirectoryEntry instance I needed to examine the name.

I see #basename and #fullName. As I browse other classes I see
#childNamesAt: and #pathName, etc.

I was just curious why #basename and not #baseName?

Thanks.

Jimmie

Jimmie Houchin wrote:
Perhaps wide use of 'basename' as a single word has been previously
established ?
http://en.wikipedia.org/wiki/Basename

We wrote a chapter on FileSystem.
Did you miss it?

        http://rmod.lille.inria.fr/pbe2/

Stef

On Jan 8, 2013, at 5:07 PM, Jimmie Houchin wrote:

On 1/8/2013 10:33 AM, Ben Coman wrote: Yes, that is established in Unix as per your link. But we are talking
about Pharo Smalltalk.

In the article you mention above they also refer to pathname, while in
FileSystem it is #pathName.
So we are not adhering to the standard of the article mentioned either.
We are not consistent to any standard, ours or theirs.

I can understand previous standards and usages. I can understand legacy.
But FileSystem is Smalltalk and FileSystem is new, replacing legacy code.

I am not advocating anything. Just saying to a new user, with fresh
eyes, it is inconsistent.

Thanks.

Jimmie

On 1/8/2013 10:35 AM, Stéphane Ducasse wrote:
> We wrote a chapter on FileSystem.
> Did you miss it?
>
> http://rmod.lille.inria.fr/pbe2/
>
> Stef

Thanks Stef.

I had not seen that.

Jimmie

On 08.01.2013, at 17:07, Jimmie Houchin <[hidden email]> wrote:

> Hello,
>
> I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it.
>
> It took me a little while to learn to do something like:
> fs := FileSystem store: (DiskStore activeClass createDefault).

Why not

fs := FileSystem disk.

??

or:

reference := FileSystem disk referenceTo: '/foo/bar.txt'.

Cheers,
Max

>
> It would be nice if there were an instance creation method like
> FileSystem createDefault   which would do the above.
>
> My utility was renaming some files. Once I had acquired a FileSystemDirectoryEntry instance I needed to examine the name.
>
> I see #basename and #fullName. As I browse other classes I see #childNamesAt: and #pathName, etc.
>
> I was just curious why #basename and not #baseName?

I guess it's like "filename". It's easier to write without camel casing and it's usually used as a "single" word.

>
> Thanks.
>
> Jimmie
>

On 2013-01-08, at 17:55, Max Leske <[hidden email]> wrote:

or:

'/foo/bar/plonk.txt' asFileReference
'/foo/bar' asFileReference


which creates a FileReference on the disk, the default

anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol.
maybe for 3.0?

On Jan 8, 2013, at 5:58 PM, Camillo Bruni <[hidden email]> wrote:

On 2013-01-08, at 18:01, Esteban Lorenzano <[hidden email]> wrote:

> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol.
> maybe for 3.0?

yes definitely :).

Jimmie, maybe you can open an issue on code.google.com/p/pharo/?
with a complete list of the methods you find confusing?

+1

>> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol.
>> maybe for 3.0?
>
> yes definitely :).
>
> Jimmie, maybe you can open an issue on code.google.com/p/pharo/?
> with a complete list of the methods you find confusing?

Thanks for all the suggestions for easier way to create references.

Part of the problem is that I did not sufficiently read the
documentation in the class comment. I also did not know of the PBE2
chapter referenced by Stef.

Part of the problem is also that the browser in 2.0 is presenting things
differently and I am not sure I understand fully what it is communicating.

When I look at the class methods in FileSystem most of them are gray and
a only few black. It is not self evident what the gray coloration means.
Also when one clicks on instance creation, the only method is #store:.  
So unless you see the class comment, then you won't see the
documentation on using FileSystem disk workingDirectory which returns a
FileSystemDirectoryEntry instance, while FileSystem disk   returns a
FileSystem instance.

I should have investigated documentation a little harder.

Jimmie

On 1/8/2013 11:01 AM, Esteban Lorenzano wrote:

On 09/01/13 12:05 AM, Jimmie Houchin wrote:
>
> Part of the problem is that I did not sufficiently read the
> documentation in the class comment. I also did not know of the PBE2
> chapter referenced by Stef.

I used to assume that class comments were empty. Nowadays, there is
often useful information there. Maybe the browser could indicate whether
or not the class comment is empty - something like '--?', when the
comment is empty.

On 1/8/2013 12:14 PM, Camillo Bruni wrote:
> On 2013-01-08, at 18:01, Esteban Lorenzano <[hidden email]> wrote:
>> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol.
>> maybe for 3.0?
> yes definitely :).
>
> Jimmie, maybe you can open an issue on code.google.com/p/pharo/?
> with a complete list of the methods you find confusing?
I opened an issue on the basename usage at:
http://code.google.com/p/pharo/issues/detail?id=7222

I wasn't really confused by anything in particular that I mentioned.
Just noting what I saw as an inconsistency in a method name.

The documentation that Stef referred to should help.
I do like the 'MyPath' asFileReference method.

What I have found confusing is the workingDirectory which is an instance
variable.

In a workspace I did the following.

Initial workingDirectory
    fr1 := FileSystem disk workingDirectory.
    fr1. " file://C:\Users\Jimmie\Pharo\images"

    fs1 := FileSystem disk.
    fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images"

New FileSystem instance
    fs2 := FileSystem disk.

workingDirectory is the same as the first instance.
    fs2 workingDirectory." file://C:\Users\Jimmie\Pharo\images"

Change workingDirectory on the new instance using the instance method
#workingDirectoryPath:
    fs2 workingDirectoryPath: Path / 'C:\Users\Jimmie'.
    fs2 workingDirectory." file://C:\Users\Jimmie"

First instance workingDirectory unchanged.
    fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images"

New FileSystem instance.
    fs3 := FileSystem disk.

workingDirectory is the same as the changed one on the second instance.
    fs3 workingDirectory." file://C:\Users\Jimmie"

    fs1 workingDirectory." file://C:\Users\Jimmie\Pharo\images"
    fs2 workingDirectory." file://C:\Users\Jimmie"

New FileSystemDirectoryEntry instance has the new workingDirectory
    fr2 := FileSystem disk workingDirectory.
    fr2." file://C:\Users\Jimmie"

What I don't understand is why using an instance method to change an
instance variable, changes something in the class which affects the
initial state of new instances.

This was an unexpected behavior for me as I was operating on an instance
variable via an instance method. At least so I thought.

I may have overlooked such, but I haven't seen any documentation about
this behavior. So I don't know if this is the desired behavior or if it
is a bug.

I was hoping for the workingDirectory to be an instance variable which
could be different for each instance. It would be nice if a FileSystem
object could be created with the desired workingDirectory.

But I imagine that the proper way to do such is to rather create a
FileReference to the desired directory and operate on it.

Just curious.

Jimmie

On 1/8/2013 11:18 PM, Yanni Chiu wrote:
The Nautilus browser in Pharo 2.0 does distinguish these classes with an
! ClassName in the browser. Then you have to click on the Comments
button to display the comment.

I was just negligent to notice and read thoroughly.

It might be nice if the these classes which have external documentation
such as in the Pharo By Example, noted such.

Jimmie

On Jan 9, 2013, at 6:05 AM, Jimmie Houchin wrote:

> Thanks for all the suggestions for easier way to create references.
>
> Part of the problem is that I did not sufficiently read the documentation in the class comment. I also did not know of the PBE2 chapter referenced by Stef.
>
> Part of the problem is also that the browser in 2.0 is presenting things differently and I am not sure I understand fully what it is communicating.


We will improve it soon.