> On 07 May 2016, at 12:08, Udo Schneider wrote:
>
> Hi Sven,
>
> > I always had the impression that Path is not meant for public use,
> > just part of the implementation. Should it not be part of the -Public
> > package then ?
> I'm a bit schizophrenic on this one :-)
The whole FileSystem design is very cool, but sometimes a bit confusing. The
first step is of course to fully understand the current design and the ideas
behind it. Only then, maybe, we can start to think about what needs to be
changed. Right now, I feel I am no ready to do that.
> My "first self" argues that Path as a part of the FileSystem API should
> indeed remain/be private. Especially because most of us still thing of paths
> as strings. And manipulating them detached from a filesystem poses some risks
> (mentioned below). In addition the class comment (IMHO rightly) states: "I'm
> a private and abstract filesystem path, independent of the string
> representation used to describe paths on a specific filesystem".
>
> My "second self" argues that a Path could denote so much more than an
> identifier in filesystem space. Just think of a navigation path in websites
> (breadcrumbs). In this context Path would be a generalized way to deal of
> structuring an abstract space by mean of string identifiers. And a
> "FileSystemPath" would be a (private - see above) subclass adding the
> filesystem behavior (like detecting absolute filesystem paths).
>
> > Maybe there are still other ways to parse a Windows path while
> > running on a Mac or Linux ?
> I'm not sure I'm getting this one.
>
> Path works the same on all platforms. You might just have to manually specify
> a delimiter if you want to parse a string. This IMHO is a good thing - you
> should know the format of strings you're getting :-)
> I've seen code like this:
>
> "Path Splitting for Windows and *nix"
> pathParts := pathString substrings: '/\'.
>
> This works /most/ of the time. It just fails when considering that e.g. "\"
> is a valid character in *nix filenames ...
>
> '/home/udos/Hello\World' substrings: '/\'. "#('home' 'udos' 'Hello' 'World')"
>
> but
>
> "Not specifying delimiter here - $/ is default then"
> Path from: '/home/udos/Hello\World'. "Path / 'home' / 'udos' / 'Hello\World'"
>
> And considering that some platforms use totally different path delimiters
> (e.g. ":" on Mac OS, "." on RISC/OS) it's IMHO cleaner to only split on one
> Character (like Path>>#from:delimiter:) and assign the responsibility of
> knowing which delimiter to use to the programmer.
>
> However ignoring "minor" platforms and issues with delimiters in names there
> is no big difference between String>>#substrings: and Path>>#from:delimiter:
> at first. But the getting back a Path is IMHO much more intention revealing
> than a collection of strings. Especially because you're getting back an
> AbsolutePath or RelativePath which is even more intention revealing and
> something you may completely miss when splitting strings.
>
>
> absoluteArray := '/home/root/file' substrings: '/'. "#('home' 'root' 'file')"
> relativeArray := ('home/root/file' substrings: '/'). "#('home' 'root'
> 'file')"
> "The distinction between absolute and relative is lost here!"
>
> absoluteArray = relativeArray. "true"
> "Both paths may have referenced the same file - but also may not"
>
> absolutePath := Path from: '/home/root/file' delimiter: $/. "Path / 'home' /
> 'root' / 'file'".
> absolutePath class. "AbsolutePath"
> relativePath := Path from: 'home/root/file' delimiter: $/. "Path * 'home' /
> 'root' / 'file'"
> relativePath class. "RelativePath".
> "The distinction between absolute and relative paths is kept.
> In #printString and class"
>
> absolutePath = relativePath. "false"
> "No danger to confuse absolute and relative paths here"
>
>
>
> Or did I get you completely wrong?
>
> CU,
>
> Udo
>
>
>
>
> On 07/05/16 10:57, Sven Van Caekenberghe wrote:
>> Hi Udo,
>>
>> That is a very good explanation, thank you.
>>
>> I always had the impression that Path is not meant for public use, just part
>> of the implementation. Should it not be part of the -Public package then ?
>>
>> Maybe there are still other ways to parse a Windows path while running on a
>> Mac or Linux ?
>>
>> Sven
>>
>>> On 07 May 2016, at 10:46, Udo Schneider
>>> wrote:
>>>
>>> Hi Johan,
>>>
>>> I remember running into similar problems because I didn't understand the
>>> FileSystem philosophy ... and dealing with strings and concatenating them
>>> is so much easier, right? :-)
>>>
>>> After reading the chapter on FileSystem several times over and over again
>>> the IMHO most important part of it to get the grasp of FileSystem is on
>>> page 13
>>> (http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/FileSystem.pdf):
>>>
>>> "
>>> FileReference = FileSystem + Path
>>> Paths and filesystems are the lowest level of the FileSystem API. A
>>> FileReference combines a p
