Proposal for std.path replacement
Lars T. Kyllingstad
public at kyllingen.NOSPAMnet
Sun Mar 6 07:33:14 PST 2011
On Sun, 06 Mar 2011 15:54:19 +0100, spir wrote:
> On 03/06/2011 12:56 PM, Lars T. Kyllingstad wrote:
>> On Sun, 06 Mar 2011 09:37:15 +0100, Rainer Schuetze wrote:
>>
>>> Looks good overall. I have a few comments and nitpicks though:
>>>
>>> > basename("dir/subdir/") --> "subdir"
>>> > directory("dir/subdir/") --> "dir"
>>>
>>> Is this what everybody expects? I'm not sure, but another possibility
>>> would be to treat these as if "dir/subdir/." is passed.
>>
>> I don't know about everybody, but it is what *NIX users expect, at
>> least. I have written those functions so they adhere to the POSIX
>> requirements for the 'basename' and 'dirname' commands.
>>
>>
>>> What is the
>>> result of directory("/") or directory("d:/")?
>>
>> "/" and "d:/", respectively. The first is what 'dirname' prints, and
>> the second is the natural extension to Windows paths. (I believe I
>> have covered most corner cases in the unittests. I think it would just
>> be confusing to add all of them to the documentation.)
>>
>>
>>> > extension("file") --> "" extension("file.ext")
>>> > --> "ext"
>>>
>>> What about "file."? I tried it on NTFS, but trailing '.' seems to
>>> always be cut off. Is it possible to create such a file on unix
>>> systems? If yes, you won't be able to recreate it from the result of
>>> basename() and extension().
>>
>> Good point. I don't know if there is any kind of precedent here. What
>> do others think?
>>
>>
>>> What about network shares like "\\server\share\dir\file"? Maybe it
>>> should also be shown in the examples? Does the "\\server" part need
>>> special consideration?
>>
>> Hmm.. that's another good point. I haven't even though of those, but
>> they should probably be covered as well. I'll look into it.
>
> What about extending the notion of 'device' (see other post) to cover
> 'http://' and "ftp://"?
> Would it be complicated?
I don't think std.path should handle general URIs. It should only have
to deal with the kind of paths you can pass to the functions in std.file
and std.stdio.
-Lars
More information about the Digitalmars-d
mailing list