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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
