[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
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:
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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] 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.
but at least the protocol is familiar. If I were starting over, I might reify paths and define #, to concatenate them.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] 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 <File class-file name manipulation.st>
On Fri, Feb 18, 2011 at 23:40, Stéphane Ducasse <stephane.ducasse@inria.fr> 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:
On Fri, Feb 18, 2011 at 23:40, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
Here is a forward of colin's answer which I like. On Fri, Feb 18, 2011 at 2:40 PM, Stéphane Ducasse <stephane. ducasse@inria.fr> wrote:
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.
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.
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 :)
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
participants (4)
-
Damien Pollet -
Max Leske -
Schwab,Wilhelm K -
Stéphane Ducasse