Hi Damien, On Fri, Mar 30, 2018 at 05:30:52PM +0200, Damien Pollet wrote: > I understand that when you want to actually open and read/write files, you > have > to resolve them in a filesystem and that's what a FileReference is for. > > But there are uses for file paths BEFORE you have a filesystem to resolve them > in. > > I was talking about a config file, in which some values are file names > (sometimes absolute paths, sometimes relative). In a config file the paths are > not resolved because the filesystem is not known; maybe I want to test the > config file parser, and I don't actually have the matching files, or maybe > they > are in a memory filesystem. > > Maybe I'm reading a Zip archive and I'm specifying a member of the archive (so > the path does not point to an actual file on disk).
FileReferences are designed to handle this situation, e.g. Let's say I've zipped up my pharo directory: (FileSystem zip: 'pharo.zip' asFileReference) open / 'pharo-local/play-cache/2018-03-29T21-49-20-403605+02-00.ph' is perfectly fine. Sending #contents to the resulting FileReference will give me the expected result. > Maybe I'm writing a command-line argument parser, and some arguments are > supposed to be file paths and I want to syntactically validate that aspect. Or > I want to ensure that an argument is relative and not absolute. Or the > argument > is a relative path from an implicit origin (unspecified as far as the > commandline parser is concerned); because the origin will be determined by > application code. Good point. FileSystem was written long before I got involved with Pharo, so I don't know whether this situation was considered, and what the expected approach was. It would still be possible to use a FileReference to do the check - there's nothing that says the path has to exist. However that does seem to be stretching the usage, so I agree that using Path makes sense in this case. > In all those use cases, using FileReferences is just incorrect, as we're not > talking about existing files, but about abstract places or navigation > instructions in a hypothetical filesystem. The comment in Path does say: "Normally users should not use me directly." So there is an out :-) I think the comment is correct though - in most cases the user should be dealing with FileReferences and not Paths. Cheers, Alistair > On 30 March 2018 at 16:57, 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. > > HTH, > Alistair > > > > 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 > > > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet
