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