On 1/3/11 10:40 AM, spir wrote:
On Mon, 3 Jan 2011 07:57:24 -0800
Jonathan M Davis<[email protected]> wrote:
Much as I have found path types to be useful at times, they can definitely be a
bit burdensome for simple operations, and simple operations are all that the
vast majority of the programs out there really care about. So, I'm tempted to
say that a path type just isn't worth the bother in std.path and leave it to a
third party library for those who really care.
As an intermediate solution, why not let standard _file_ operations have plain
string pathes as parameters, but provide a Path type in std.path. Anyway, it
won't bother you if let it alone ;-)
An even lighter alternative would be to define
alias string[] Path;
then (re)write all path functionality funcs as pseudo-methods taking
a string[] as first arg, to benefit from the "unversal func call
syntax" (which you like so much, and myself as well), that currently
works only for arrays. [Except for the pseudo-constructor.] Worth
exploring?
Honestly, I don't think so. Global aliases like that are not all that
great because they suggest a type with only path-specific primitives
whereas in reality it's not quite all that.
I agree that sometimes you could use a broken-down path (e.g. per
Steve's examples) but as Steve also said they are not commonly encountered.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
