Path as an object in std.path
Dylan Knutson
tcdknutson at gmail.com
Wed Jun 5 13:19:21 PDT 2013
> I don't have a strong opinion regarding Path object vs. string
> functions, and I agree both have advantages and disadvantages.
> But I would be opposed to having both.
Personally, I'd prefer to just use the Path struct in std.path.
While a Path can be represented as a string, it's not the same
concept (the same way that a DateTime can be represented as an
integer, but we don't just pass times around as raw integer
types).
However, I can't imagine that'd be feasible as it'd break a lot
of code. My suggestion would be to just keep the freestanding
functions to operate on raw strings, and then migrate over code
that depends on std.path to use the Path struct as needed. I
realize that this is easier said than done, but even then it
shouldn't be a lot of work as Path can implicitly be converted to
a string.
This makes its integration into existing codebases/Phobos
literally as easy as using "Path my_path = `foo\bar`" instead of
"string my_path = `foo\bar`". You lose no functionality but gain
type safety if you have to do any future refactoring.
> I wouldn't like to create an "object" just to call isAbsolute.
Agreed. The best course of action would probably be keep the raw
functions as they exist (think of them as the static versions of
Path methods). However, for large applications, the type safety
of a Path object makes working with paths much easier.
More information about the Digitalmars-d
mailing list