Its awkward to deal with. Some notes here...https://pharo.fogbugz.com/default.asp?13094#154946 On Fri, Oct 14, 2016 at 12:05 AM, Damien Pollet <damien.pollet@gmail.com> wrote:I explored a bit more and I'm stumped. Fixing it for Unix is easy, but it breaks Windows paths, because those use their first element to store the drive name (c: d: etc) which shouldn't be preceded by a /.I'm starting to think the Absolute/Relative dichotomy is either wrong or incomplete and we need windows-specific subclasses. Doesn't it feel strange that we can pass strings with different syntax and assumptions to Path class >> from: and get instances from the same classes?On 8 October 2016 at 19:21, Damien Pollet <damien.pollet@gmail.com> wrote:It's a breaking change and I don't know if there's a way to do it with proper deprecation��� my hope is that there are not many users of it, but I haven't checked yet. Any opinions among users of FileSystem?On 8 October 2016 at 19:12, stepharo <stepharo@free.fr> wrote:So damien what is the solution?
Le 7/10/16 �� 18:18, Damien Pollet a ��crit��:
Path >> printString returns a self-evaluating representation, which is fine. Its symmetric is thus Compiler >> evaluate: aString.
(Path from: aString) parses the unix/url representation of a path and results in a Path instance. As far as I understand, #fullName should be the symmetric of that, so that we always have (modulo syntactic normalization, maybe) :
(Path from: aString) fullName = aString
Note that there's an edge case with the empty string that is wrong (at least it should be confusing to unix guys):
Path from: ''. "Path root"
Usually the absolute path for the root of the filesystem is explicitly noted '/', and an empty path is equivalent to '.'--
--
--