(2010/09/17 8:03), Jonathan M Davis wrote:
On Thursday, September 16, 2010 04:27:17 SHOO wrote:
(2010/09/16 0:45), Jonathan M Davis wrote:
On Wednesday 15 September 2010 05:06:58 SHOO wrote:
I think that these features should be refined more, too. I am confused
that the handling of strings and path are mixed.
A path _is_ a string. It's a string which indicates where on the file
system a file is located. All of the functions in std.path are,
therefore, string-related. However, they all relate to paths as opposed
to strings in general, so I don't see what's mixed about them.
- Jonathan M Davis
That is right.
However, what about vice versa? string is not path in some cases.
For example, the thing which "exists" means may not be a file. (URL,
ISBN, words, system specialized function, and so on. Strings may not
show only a pass.)
The thing which "join" connects may not be a pass. (You cannot guess
result of join("path", "to", "the", "file") is "path/to/the/file" or
"topaththepathfile". And this brings on conflict between std.string.join
and std.path.join)
You cannot be convinced that "getSize" is the capacity of the file. (It
may be the allocated memory size or the NIL terminated string length.)
This is only a part of the examples.
Users have wrong how to use if users will not treat it carefully.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
That sort of stuff stems from the fact that a path is not its own type. std.path
contains functions for dealing with strings that are paths. If the strings that
you give it aren't valid paths, then either they won't work or you won't get
valid paths out of them (depending on the function and what it's doing). Sure,
std.path.join() conflicts with std.string.join(), but they do different things,
albeit similar.
Complaining about std.path using strings and that those strings may not be valid
paths would be like complaining that std.xml uses strings and that those strings
may not be valid xml. The functions are designed for handling strings that are
paths, and at least some of them check that the strings they're given are valid
paths.
I really don't understand what the problem is. std.path deals with strings that
are paths. std.string deals with strings in general. And std.file deals with
file
operations. They are all quite distinct, even if some function names do overlap
(which is one of the reasons that we have modules rather than a global
namespace).
- Jonathan M Davis
Your opinion is not pertinent. Complaining about std.path using strings
of invalid paths is not related.
When user code showed it, you cannot judge it quickly:
class A{
...
File foo()
{
return File(join(p, "bar"));
}
...
}
What is "join" meaning? std.stirng.join ? std.path.join ? User-defined
function? Alias?
The name called join is too general to recognize that it is related to a
path of filesystem. (Sure, it is not to have been limited join.)
If it makes a model for path as one way, it is a problem broken off.
And therefore, as for the problem that I explained, example of behavior
of std.xml is totally the other problem.
Rather I think that the behavior of std.xml is extremely right.
If I compare behavior with std.xml, I think std.path should have Path
struct so that std.xml has Document, Item, Elements, etc.
If your opinion was right, std.xml would not have any user-defined types.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
