Need your point of view on FSPath * and others

Colin

I'm continuing adding comments to FS.
1- A question about

FSPath class>>* aString
       
        ^ self with: aString

I would like to deprecated FSPath class>>* and use with: since this is the message
and

What do you think?
I really prefer for static analysis point of view not to pollute numerical behavior with others.
Avoiding ad-hoc polymorphism will help us to build static checker in the future.


2- Then I was wondering if it would not be good to have validating creation methods

(FSPath * 'parent/child/') isRelative
        true
(FSPath * '/parent/child/') isAbsolute
        false
because the string is not checked
FSPath * '/parejhkjhhg %% ^%$%^(%$546547675 nt??child/'

I saw that there is
        readFrom: aStream delimiter: aCharacter

so I created an unchecking instance creation category and I added with: and * in it.
And added  comments

3- Then finally the following confuses me
       
(FSPath with: 'parent/child/') isRelative true
(FSPath with: '/parent/child/') isRelative true
(FSPath with: '') isRelative false

Either with: create relative path or isRelative is not consistent.
If with: creates relative path then the last one should be true
or isRelative should return false on the second one. ?

4 - about FSPath root
we have

root
        "Return the relative root path"
        ^ self with: ''

FSPath root
  returns /
and I like that

Now what about defining root as

root
        ^ self with: '/'

It would be more consistent. Now it breaks everything. So I did not do it :)



May be I'm tired after 4 ours teaching and 6 hours train.



Thanks for your time

Stef

Concerning question 4:
If I remember correctly, the problem is that a path is absolute if "path at: 1" answers ''. "FSPath with: '/parent/child'" creates a path with size 1 and not size three as you would expect in this case. So in my oppinion, the message #with: does not behave like one would expect. I have had troubles with this myself. I would suggest to change the behaviour of #with:.

Cheers,
Max



On 18.02.2011, at 23:40, Stéphane Ducasse wrote:

Stef,

I am not sure that #* would be all that confusing: I tend not to multiply path names all that often :)  However, your question is well taken.  How about #any or #all?

Attached are some methods that I use to ease the transition from Dolphin.  Most of the calling code needs to be modified anyway (to change to Linux conventions), but at least the protocol is familiar.  If I were starting over, I might reify paths and define #, to concatenate them.

Bill




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Friday, February 18, 2011 5:40 PM
To: Colin Putney
Cc: Pharo Development
Subject: [Pharo-project] Need your point of view on FSPath * and others

Colin

I'm continuing adding comments to FS.
1- A question about

FSPath class>>* aString

        ^ self with: aString

I would like to deprecated FSPath class>>* and use with: since this is the message
and

What do you think?
I really prefer for static analysis point of view not to pollute numerical behavior with others.
Avoiding ad-hoc polymorphism will help us to build static checker in the future.


2- Then I was wondering if it would not be good to have validating creation methods

(FSPath * 'parent/child/') isRelative
        true
(FSPath * '/parent/child/') isAbsolute
        false
because the string is not checked
FSPath * '/parejhkjhhg %% ^%$%^(%$546547675 nt??child/'

I saw that there is
        readFrom: aStream delimiter: aCharacter

so I created an unchecking instance creation category and I added with: and * in it.
And added  comments

3- Then finally the following confuses me

(FSPath with: 'parent/child/') isRelative true
(FSPath with: '/parent/child/') isRelative true
(FSPath with: '') isRelative false

Either with: create relative path or isRelative is not consistent.
If with: creates relative path then the last one should be true
or isRelative should return false on the second one. ?

4 - about FSPath root
we have

root
        "Return the relative root path"
        ^ self with: ''

FSPath root
        returns         /
and I like that

Now what about defining root as

root
        ^ self with: '/'

It would be more consistent. Now it breaks everything. So I did not do it :)



May be I'm tired after 4 ours teaching and 6 hours train.



Thanks for your time

Stef

On Feb 19, 2011, at 2:24 PM, Schwab,Wilhelm K wrote:

> Stef,
>
> I am not sure that #* would be all that confusing: I tend not to multiply path names all that often :)  However, your question is well taken.  How about #any or #all?

but any or all do not really have more sense.

> Attached are some methods that I use to ease the transition from Dolphin.  Most of the calling code needs to be modified anyway (to change to Linux conventions),

thanks I will have a look.

On Fri, Feb 18, 2011 at 23:40, Stéphane Ducasse
<[hidden email]> wrote:
> I would like to deprecated FSPath class>>* and use with: since this is the message

Yes but what about / both class and instance side?

> 2- Then I was wondering if it would not be good to have validating creation methods
>
> (FSPath * 'parent/child/') isRelative
>        true
> (FSPath * '/parent/child/') isAbsolute
>        false

I think those should raise exceptions in this case. FSPath is for
building paths step by step, so the argument should not contain
separators (or, it means you want a path with only one element with
separators in its name, which will probably cause problems with the
OS. But see below.

> I saw that there is
>        readFrom: aStream delimiter: aCharacter

And this one is called by FSFilesystem >> #pathFromString:
The problem here is that only the filesystem knows which separator
makes sense. FSPath alone does not know how to parse a string, which
explains why the above methods do not check: it's not their
responsibility. So probably FSPath should know for which kind of
filesystem it's meant, or there should be platform-specific subclasses
of it.

> (FSPath with: 'parent/child/') isRelative true
> (FSPath with: '/parent/child/') isRelative true
> (FSPath with: '') isRelative false

Same as above and what Max said, those always create relative paths
with one step named by the string you pass, unparsed. Now we can
discuss using the empty string as a convention for the root, or a
proper null object…

> Now what about defining root as
>
> root
>        ^ self with: '/'
>
> It would be more consistent. Now it breaks everything. So I did not do it :)

Not really consistent, because / is a separator. Using it as the name
for the first element of a path does not make sense. FSPath root /
'plop is not //plop :)

> May be I'm tired after 4 ours teaching

teaching bears, that's a concept :)

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Thanks damien


On Feb 20, 2011, at 12:53 AM, Damien Pollet wrote:

Here is a forward of colin's answer which I like.


On Fri, Feb 18, 2011 at 2:40 PM, Stéphane Ducasse
<stephane.
 [hidden email]> wrote:
I think that in an ideal world, each selector would have a single
"meaning" and all methods with the same selector would be polymorphic
to each other. But we're very, very far from that world, and in
practice, I don't think there's anyway a static analysis tool can rely
on two methods with the same selector being polymorphic.

With that in mind, I added the #/ and #* methods to make the
filesystem API easier to use. I think binary selectors are
under-exploited in Smalltalk, and we'd gain a lot in terms of succinct
and readable code by making better use of them.

> 2- Then I was wondering if it would not be good to have validating creation methods
>
> (FSPath * 'parent/child/') isRelative
>        true
> (FSPath * '/parent/child/') isAbsolute
>        false
> because the string is not checked
> FSPath * '/parejhkjhhg %% ^%$%^(%$546547675 nt??child/'

That's not how paths are meant to be used - the string arguments
should be file- or directory names, not path fragments. #* creates a
relative path (it's meant to be similar mnemonically to
./parent/child, while #/ creates an absolute path.

(FSPath * 'parent' / 'child') isRelative "true"
(FSPath / 'parent' / 'child') isAbsolute "true"


> I saw that there is
>        readFrom: aStream delimiter: aCharacter
>
> so I created an unchecking instance creation category and I added with: and * in it.

It's not a matter of checked and unchecked so much as parsed and
unparsed. #/ and #* provide a mini-DSL for building up paths, while
#readFrom:delimiter: parses path strings.

> 3- Then finally the following confuses me
>
> (FSPath with: 'parent/child/') isRelative true

That creates to a relative path to a file/directory called
'parent/child'. In bash you'd escape the slashes like this:

parent\/child\/

> (FSPath with: '/parent/child/') isRelative true

That's a relative path to '/parent/child'. In bash: /\parent\/child\/

> (FSPath with: '') isRelative false

That's an absolute path to the root of the file system. Absolute paths
have an empty first element. If you consider $/ the a separator,
'/usr/local/bin' has an empty first element, right?

> Either with: create relative path or isRelative is not consistent.
> If with: creates relative path then the last one should be true
> or isRelative should return false on the second one. ?

Ok, it's a bit of an unusual case, but I think it's important to be
able to represent paths like \/parent\/child. Their perfectly valid as
far as the filesystem is concerned, and we want to be able to work
with such oddly-named files.

I suppose that, strictly speaking, the most consistent way to
represent the root directory is

root
   ^ self withAll: #('' '')

It still ends up being a bit of a special case, though.

Colin