On 03/06/2011 09:37 AM, Rainer Schuetze wrote:
Looks good overall. I have a few comments and nitpicks though:
I think all your questions are sensible, Rainer.
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. What is the result of
directory("/") or directory("d:/")?
Depends. We must make clear whether such funcs work:
1. indifferently for file and dir names, in which case we get the above results,
2. differently for file & dir names, in which case we would have "dir/subdir/"
as result of both operations above,
3. only for file names, in which case we throw an error when these functions
are called on dir names.
I find both solutions 1. and 2. conceptually problematic; the second one only a
bit less. Maybe the only sensible choice is 3.?
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().
This is /really/ problematic, indeed! The splitting operation *must* be
reversable in all cases. In other other words, file name/path recomposition
must be symmetric of splitting it.
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?
I think there should be a special case similar to windows drive names. Maybe,
instead of a notion of drive, have a notion of 'device', which could then cover
network connexion. Then, a full file path/name would be composed of:
deviceName | dirName || baseName | extension
One issue is defining the appropriate 'joint'/sep between deviceName & dirName.
(See split <--> recomposition above.)
What do you think?
Denis
--
_________________
vita es estrany
spir.wikidot.com
