[phobos] std.path proof of concept

[Andrei Alexandrescu]

On 04/26/2010 04:08 PM, Lars Tandle Kyllingstad wrote:
> Are you envisioning a system that auto-detects whether something is a
> Windows or a POSIX path and converts it to some OS-agnostic internal
> representation? E.g. something like
>
> // Auto-detect Windows path
> auto path = Path("c:\\foo\\bar.baz");

I wasn't thinking of that. More like some common primitives that could 
deal with Windows paths and Unix paths. The separator is already 
abstracted, and the remaining difference is the existence of a drive 
letter in Windows (that I notice some Unix shells are starting to 
replace with a protocol such as smb: or sftp:).

> The only other option I can see is to have std.path automatically work
> with Windows paths on Windows and POSIX paths on POSIX -- which is
> exactly what I'm suggesting.
>
>
> Anyway, I'm not married to this idea, I just think it's a good one. ;)
>
> I still think something needs to be done to std.path, though (and I'm
> still volunteering to do it). Did any of my other suggestions seem
> worthwhile, or are people happy with the module the way it is? Are there
> other suggestions?

I love the way you set up things here:

http://kyllingen.net/code/ltk/doc/path.html

It's just that I so much believe it would sit better elsewhere. It's a 
great design hitting on an unfit problem. For example, let's assume you 
convince me there really is a need for Unix path manipulation on Windows 
(which I'm not, but let's say I am). Then I see I can use Windows paths 
on Unix. Yay! That's what I call a cool design. But wait. When would you 
need that? Well, most never. That's why I feel there's some lack of 
fitness in there.

How about this: we focus on an API that allows you to use the alternate 
separator on Windows ("/") for virtually all Posix primitives. At least 
in theory, a Windows path without a drive is a Posix path.


Andrei