On Tuesday 27 June 2017 05:01 PM, Sven Van Caekenberghe wrote:
A FileReference holds a FileSystem and a Path. A Path is just a collection of elements that leads to a location, the leaf possibly being interpreted as a file with an extension (although that last point is just a convention). It seems great effort was put into avoiding the use of separators.
Pharo is an object oriented system with appropriate abstractions, FileSystem gives us one approach to this difficult problem.
+1. Pharo's elegant design captures the essentials of naming file objects.
In your reasoning, your truth, your reference is always the Unix file system and the way paths are handled > FileLocator root / 'foo' / 'bar' / 'readme.txt'.
is more abstract (fitting to the original goal) then
'/foo' asFileReference / 'bar/readme.txt'.
because it totally avoids a reference to the platform dependent path separator.
Agreed that the first form is quite elegant. But I see no harm in graceful acceptance of the second. Such strings could be encountered in scripts and variables. It is also a convenient shorthand.
Windows is an important target for Pharo, they use $\ not $/.
Windows cmd shell uses only $\ while its API accepts both. This is a eternal meme thread in Win32 mailing lists ;-).
Another point is the distinction between internal/external and/or concrete/abstract paths. Should something like '..' remain part of a path. Never, always, only when it can be resolved ? What about special characters ?
Path elements are platform-specific and their resolution to specific inode is context-specific. Canonicalization is only needed in low level code.
Should we support ~ ? Sometimes I would like that too, but maybe
FileLocator home
Elements like ~ or $HOME are expanded by shell before calling host API. GUI shells based on XDG also expand other variables (see ~/.config/user-dirs.dirs) It is upto Pharo to define its own variables and expand them just before calling APIs (say from {$PHARO_HOME, "pharo.conf"} Regards .. Subbu