Jump to page: 1 2
Thread overview
[phobos] std.path proof of concept
Apr 26, 2010
Ellery Newcomer
Apr 28, 2010
Ellery Newcomer
Apr 26, 2010
Ellery Newcomer
Apr 23, 2010
Walter Bright
April 23, 2010
I am convinced that what I've proposed is a good idea, so I made a tiny proof-of-concept version of the module.

In fact, I found an even better way to do it:  Instead of putting the functions inside structs, I just have one template of which the appropriate instantiation is mixed into the module scope.  So, on Windows,

     getDirectory("c:\\foo\\bar.txt")         -->  "c:\\foo"
     Path!Posix.getDirectory("/foo/bar.txt")  -->  "/foo"

In this way, there is no code duplication and no more work for the library maintainer, only more flexibility for the user.  Check out the code and documentation if you don't believe me:

   http://github.com/kyllingstad/ltk/blob/master/ltk/path.d
   http://kyllingen.net/code/ltk/doc/path.html


-Lars
April 23, 2010
I would make a suggestion that the Windows version allows forward slash for a dir separator as input.  "C:/foo/bar.txt" and "C:\\foo/bar.txt" are both valid paths on Windows.

-Steve



----- Original Message ----
> From: Lars Tandle Kyllingstad <lars at kyllingen.net>
> To: Phobos mailing list <phobos at puremagic.com>
> Sent: Fri, April 23, 2010 10:51:12 AM
> Subject: [phobos] std.path proof of concept
> 
> I am convinced that what I've proposed is a good idea, so I made a tiny proof-of-concept version of the module.

In fact, I found an even better
> way to do it:  Instead of putting the functions inside structs, I just have one template of which the appropriate instantiation is mixed into the module scope.  So, on Windows,


> getDirectory("c:\\foo\\bar.txt")         --> "c:\\foo"
    Path!Posix.getDirectory("/foo/bar.txt")
> -->  "/foo"

In this way, there is no code duplication and no more
> work for the library maintainer, only more flexibility for the user.  Check out the code and documentation if you don't believe me:


> http://github.com/kyllingstad/ltk/blob/master/ltk/path.d

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


-Lars
_______________________________________________
phobos
> mailing list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos



April 23, 2010
On 04/23/2010 10:23 AM, Steve Schveighoffer wrote:
> I would make a suggestion that the Windows version allows forward slash for a dir separator as input.  "C:/foo/bar.txt" and "C:\\foo/bar.txt" are both valid paths on Windows.

Makes sense. On an overall note, without having much time to look into this, I wish very strongly we strive to define OS-independent path abstractions before defining OS-dependent ones. Once the Windows vs. Posix breach is in, it'll only grow larger because it requires less design to put stuff in there.

Andrei
April 23, 2010

Steve Schveighoffer wrote:
> I would make a suggestion that the Windows version allows forward slash for a dir separator as input.  "C:/foo/bar.txt" and "C:\\foo/bar.txt" are both valid paths on Windows.
>
> 

True, but you have to be careful using / on Windows, because I regularly run into situations where it does not work. std.path should be able to correctly read and parse input that uses /, but its output should always favor \
April 26, 2010
On 04/23/2010 05:26 PM, Andrei Alexandrescu wrote:
> On 04/23/2010 10:23 AM, Steve Schveighoffer wrote:
>> I would make a suggestion that the Windows version allows forward slash for a dir separator as input. "C:/foo/bar.txt" and "C:\\foo/bar.txt" are both valid paths on Windows.
>
> Makes sense. On an overall note, without having much time to look into this, I wish very strongly we strive to define OS-independent path abstractions before defining OS-dependent ones. Once the Windows vs. Posix breach is in, it'll only grow larger because it requires less design to put stuff in there.

I think I may be explaining myself a bit badly here, so please allow me to clarify:

For the most part, I want std.path to work *just as it does now*.

If you call doStuffWith(path) on POSIX, it does stuff in the POSIX way, and if you call it on Windows, it does stuff in the Windows way.  Code using it will automatically work on both platforms.

The only difference will be that if you for some reason need to manipulate non-native paths, you will be allowed to do so by adding a prefix to your functions, e.g. Path!posix.doStuffWith(path).


Rationale:

  * The code is already in Phobos, it's just string manipulation
    and doesn't require any special OS support, and there is
    thus *no need* to hide it from the user inside version(OS)
    blocks.

  * Handling non-native paths is not an obscure need.  Examples
    include:
      - FTP and similar
      - Archive manipulation (for instance, the ZIP format uses
        POSIX paths internally)

I'd argue that this doesn't introduce more of a Windows/POSIX breach than there already is in Phobos.  I mean, in principle there is nothing preventing you from adding OS-specific stuff to std.stdio except common sense, and it will be the same here.

-Lars
April 26, 2010
I looked at the design. It is very solid and elegant, but I suggest we save it for a different opportunity. Scenarios in which code running on a platform yet needs extensive functionality for the other are a tad tenuous.

Andrei

On 04/26/2010 03:01 AM, Lars Tandle Kyllingstad wrote:
> On 04/23/2010 05:26 PM, Andrei Alexandrescu wrote:
>> On 04/23/2010 10:23 AM, Steve Schveighoffer wrote:
>>> I would make a suggestion that the Windows version allows forward slash for a dir separator as input. "C:/foo/bar.txt" and "C:\\foo/bar.txt" are both valid paths on Windows.
>>
>> Makes sense. On an overall note, without having much time to look into this, I wish very strongly we strive to define OS-independent path abstractions before defining OS-dependent ones. Once the Windows vs. Posix breach is in, it'll only grow larger because it requires less design to put stuff in there.
>
> I think I may be explaining myself a bit badly here, so please allow me to clarify:
>
> For the most part, I want std.path to work *just as it does now*.
>
> If you call doStuffWith(path) on POSIX, it does stuff in the POSIX way, and if you call it on Windows, it does stuff in the Windows way. Code using it will automatically work on both platforms.
>
> The only difference will be that if you for some reason need to manipulate non-native paths, you will be allowed to do so by adding a prefix to your functions, e.g. Path!posix.doStuffWith(path).
>
>
> Rationale:
>
> * The code is already in Phobos, it's just string manipulation
> and doesn't require any special OS support, and there is
> thus *no need* to hide it from the user inside version(OS)
> blocks.
>
> * Handling non-native paths is not an obscure need. Examples
> include:
> - FTP and similar
> - Archive manipulation (for instance, the ZIP format uses
> POSIX paths internally)
>
> I'd argue that this doesn't introduce more of a Windows/POSIX breach than there already is in Phobos. I mean, in principle there is nothing preventing you from adding OS-specific stuff to std.stdio except common sense, and it will be the same here.
>
> -Lars
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
April 26, 2010
Andrei Alexandrescu <andrei at ...> writes:

> 
> I looked at the design. It is very solid and elegant, but I suggest we save it for a different opportunity. Scenarios in which code running on a platform yet needs extensive functionality for the other are a tad tenuous.
> 

Part of the point of the path manipulation routines in dmdz.d was to get around the fact that dmd/windows doesn't have posix path manipulation. Another part was to convert from one to the other. I don't think such scenarios are tenuous at all. As far as abstractions are concerned, though, no idea.

ps Lars, what do you think of my path2list (splits a path into an array [range?] of the path elements) and its inverse? It looks like it could be implemented very cleanly in your rewrite.

April 26, 2010
On 04/26/2010 01:10 PM, Ellery Newcomer wrote:
> Andrei Alexandrescu<andrei at ...>  writes:
>
>>
>> I looked at the design. It is very solid and elegant, but I suggest we save it for a different opportunity. Scenarios in which code running on a platform yet needs extensive functionality for the other are a tad tenuous.
>>
>
> Part of the point of the path manipulation routines in dmdz.d was to get around the fact that dmd/windows doesn't have posix path manipulation. Another part was to convert from one to the other. I don't think such scenarios are tenuous at all. As far as abstractions are concerned, though, no idea.

I see. But since zip files work on both Windows and Unix, there must be a common ground of functionality that works for both. I'm hoping to insist on that instead of enacting a schism. After the schism, widening the incompatibilities will become the path of least resistance.

> ps Lars, what do you think of my path2list (splits a path into an array [range?] of the path elements) and its inverse? It looks like it could be implemented very cleanly in your rewrite.

I suggest we go with lazy ranges throughout. No memory allocation unless the user asks for it by calling std.array.array(range).  For example, splitter() vs. split() was a huge accelerator in virtually all my text processing programs.


Andrei
April 26, 2010
On 04/26/2010 09:31 PM, Andrei Alexandrescu wrote:
> On 04/26/2010 01:10 PM, Ellery Newcomer wrote:
>> Andrei Alexandrescu<andrei at ...> writes:
>>> I looked at the design. It is very solid and elegant, but I suggest we save it for a different opportunity. Scenarios in which code running on a platform yet needs extensive functionality for the other are a tad tenuous.
>>>
>>
>> Part of the point of the path manipulation routines in dmdz.d was to
>> get around
>> the fact that dmd/windows doesn't have posix path manipulation.
>> Another part was
>> to convert from one to the other. I don't think such scenarios are
>> tenuous at
>> all. As far as abstractions are concerned, though, no idea.
>
> I see. But since zip files work on both Windows and Unix, there must be a common ground of functionality that works for both.

That's because any program/library that manipulates raw zip files on Windows must also have some POSIX path manipulation capabilities.  Right now, that's in Phobos, but it's hidden from the user.


> I'm hoping to
> insist on that instead of enacting a schism. After the schism, widening
> the incompatibilities will become the path of least resistance.

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 don't think that will work, because the above is a perfectly valid POSIX path as well, except it's the name of a single file.  Just try typing

   touch 'c:\foo\bar.baz'

at a Linux command prompt.


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?

-Lars
April 26, 2010
On 04/26/2010 08:10 PM, Ellery Newcomer wrote:
> Andrei Alexandrescu<andrei at ...>  writes:
>
>>
>> I looked at the design. It is very solid and elegant, but I suggest we save it for a different opportunity. Scenarios in which code running on a platform yet needs extensive functionality for the other are a tad tenuous.
>>
>
> Part of the point of the path manipulation routines in dmdz.d was to get around the fact that dmd/windows doesn't have posix path manipulation. Another part was to convert from one to the other. I don't think such scenarios are tenuous at all. As far as abstractions are concerned, though, no idea.
>
> ps Lars, what do you think of my path2list (splits a path into an array [range?] of the path elements) and its inverse? It looks like it could be implemented very cleanly in your rewrite.

Absolutely, and I think it would be a useful addition.  I think Andrei is right that it should be lazy, though.

-Lars
« First   ‹ Prev
1 2