Proposal for std.path replacement

[spir]

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?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com