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
>



-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Reply via email to