Hi Alistair, > On Mar 30, 2018, at 7:57 AM, Alistair Grant <[email protected]> wrote: > > Hi Damien, > >> On 30 March 2018 at 14:59, Damien Pollet <[email protected]> wrote: >> The class Path from FileSystem is documented as private… but it should be >> public, shouldn't it? >> >> First hint is that it's named with a public name: (Path not FileSystemPath). >> >> Then, consider the following use-case : if you have a file name in some >> config file (.ini, .toml…) then that's really a Path, not a resolved >> FileReference. > > The file name is implicitly attached to a file system, so it is > resolved (using Pharo terminology). If you pass the path to a > program, e.g. an editor, it has enough information to be able to open > the file. > > In Unix, everything is mounted on the root file system, so there's no > need to specify a file system. Pharo's model allows for multiple file > systems, e.g. the disk, and multiple memory and zip file systems. > > Path's by themselves don't provide much functionality - you can't > actually access the file or directory you think is represented by the > path; you have to know which file system the path is attached to. > > It's the FileReference that associates the path and the file system, > and provides all the public interface.
But isn't the notion of a default file system (the root of the file system on the current machine, or the current image directory) so clear and natural that there be a public API that, by default, resolves past he against all that root? It seems to me that the benefit of the convenience here is large. > > HTH, > Alistair Eliot, _,,,^..^,,,_ (phone) > > >> I'm not talking about RelativePath and AbsolutePath, those can be hidden >> away since Path provides the factory and DSL methods. IMHO they should still >> be renamed to a more private name. >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >
