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