Path as an object in std.path

Timothee Cour thelastmammoth at gmail.com
Wed Jun 5 13:28:26 PDT 2013


currently there's no way to perform cross-platform operations.

what about:
---
enum Platform{Posix,Windows}
version(Posix) enum PlatformDefault=Platform.Posix; else enum
PlatformDefault=Platform.Windows;
struct Path(T=PlatformDefault){}

void main(){
Path!(Platform.Posix) path="a\b";
auto path2=path.to!Path;
}
---

it allows current usage with no modification, and allows cross-platform
logic.


On Wed, Jun 5, 2013 at 1:19 PM, Dylan Knutson <tcdknutson at gmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130605/ced7b836/attachment.html>


More information about the Digitalmars-d mailing list