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
