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 <[email protected]> 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 <[email protected]> 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 '.' >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
