On Thursday, 6 June 2013 at 07:26:53 UTC, Flamaros wrote:
On Wednesday, 5 June 2013 at 06:27:46 UTC, Dylan Knutson wrote:
Hello,
I'd like to open up the idea of Path being an object in
std.path. I've submitted a pull
(https://github.com/D-Programming-Language/phobos/pull/1333)
that adds a Path struct to std.path, "which exposes a much
more palatable interface to path string manipulation".
As jmdavis points out, this has previously been discussed.
However, I can't find that discussion, and I think that the
benefits of including an OO way to deal with paths is a
serious gain for the standard library.
Why I think it should be reconsidered for inclusion in the std
(listed in the pull):
* Adds a (more) platform independent abstraction for path
strings.
* Path provides a type safe way to pass, compare, and
manipulate arbitrary path strings.
* It wraps over the functions defined in std.path, so behavior
of methods on Path are, in most cases, identical to their
corresponding module function.
I'd like some feedback on what others think about this; I'd
hate to see this commit closed due to a discussion that
happened at a different point in D's development when the
language had different needs.
Thank you.
I like the idea to manipulate paths trough an object. API that
taking path as parameter as better typed than with string. It's
really usefull for file loaders, it's affirm the method will do
path related operation and expect a particular string format.
Some methods seems miss like completeBaseName and
completeSuffix.
You can take a look to : Qt API
http://qt-project.org/doc/qt-4.8/qfileinfo.html
The bad thing with the Qt API it's we can't know which method
do a file system access, that why I prefer having 2 separated
ojects.
It would be good to have the FileInfo object.
Having an object will also remove format normalization, with a
string as parameter the normalization method have to always be
called.
