On 6/6/13 1:41 PM, Walter Bright wrote:
> On 6/6/2013 8:57 AM, Lars T. Kyllingstad wrote:
>> On Thursday, 6 June 2013 at 15:41:51 UTC, Dylan Knutson wrote:
>>> FWIW, having Path be an object adds consistency with the rest of
>>> Phobos, which
>>> has many entities which could be expressed as primitives, expressed as
>>> objects. To name a few, DateTime is an object, File is an object, and
>>> DirEntry
>>> is an object. Yes, they could be described as integers, or a pointer,
>>> or a
>>> string, but it's less cognitive load on the developer to recognize
>>> them as
>>> separate types.
>>
>> "Reducing cognitive load" is not the main reason these are objects.
>> DateTime
>> lumps together no less than six integers. File adds automatic resource
>> management via reference counting. DirEntry caches file information to
>> avoid
>> repeated filesystem lookups. And so on.
>
> It's hard to see what value there is in a type that is simply a wrapper
> around an existing type, and which provides implicit conversions
> too/from that existing type so that they can be intermixed arbitrarily.
>
> At the end, that's nothing more than:
>
> alias string Path;

No, you get to check the conversions going one way.

If you destroy, destroy in style. This is a wrong argument.


Andrei

On Thu, 06 Jun 2013 13:47:42 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 6/6/13 1:13 PM, Steven Schveighoffer wrote:
>>> buildNormalizedPath(s1) == buildNormalizedPath(s2);
>>>
>>> and
>>>
>>> p1 == p2;
>>
>> This can be done without allocations.
>
> Interesting. "Show me the code!"

I think Lars summed it up nicely.  It's not full working code yet, but it shows how one can do the path splitting and normalization lazily.

However, it should be noted that buildNormalizedPath cannot be done without allocations, just the full comparison.

-Steve

On Thu, 06 Jun 2013 13:50:13 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> For example, what about symlinks?

Path operations should not require a real filesystem.  They are string manipulations, nothing more.

There is huge value in that.

-Steve

On 6/6/2013 10:47 AM, Andrei Alexandrescu wrote:
> On 6/6/13 1:13 PM, Steven Schveighoffer wrote:
>>> buildNormalizedPath(s1) == buildNormalizedPath(s2);
>>>
>>> and
>>>
>>> p1 == p2;
>>
>> This can be done without allocations.
>
> Interesting. "Show me the code!"

Not necessary - it is trivially obvious to the most casual observer!

(You just use the same logic that normalizes the path to do the comparison.)

On Thursday, June 06, 2013 10:27:28 Walter Bright wrote:
> But there's no getting around the fact
> that "File" and "file" are different paths under Windows, and are the same
> under Linux.

I think you got that backwards. ;)

- Jonathan M Davis

On Thursday, June 06, 2013 13:45:44 Andrei Alexandrescu wrote:
> > D and Phobos aren't considered stable by any
> > standard; I don't think we should treat them like they're set in stone.
> > Also, deprecation gives developers plenty of time to update their code
> > (if they have to at all).
> 
> I think this opinion is very unlikely to enjoy popularity. We actively /want/ to make Phobos more stable, so using the argument that it's not yet stable to add more instability is sure to fit the pattern of some list of fallacies. Besides, the corresponding benefits (the best solid argument that could be constructed) are at least according to some not that large to justify the cost of breakage.

Agreed. Breaking stuff in an effort to create a solid, stable API is one thing (and at this point, we want to minimize even that as much as we reasonably can). Constantly going back and rebreaking stuff is quite another. We already redid std.path. It went through the full review process and was voted in. We want to move towards being _more_ stable not less. Some API breakage will still be necessary (like replacing std.xml or the streaming modules), but it's a cost that we want to avoid when it isn't necessary. Each module redesign must justify itself, and the simple fact that other modules have already been redesigned is not enough for that. Not to mention, over time, it should arguably require _more_ justification to redo a module (or make any breaking change in Phobos), because more people are using it, and we really do want to be stable.

- Jonathan M Davis

On Thursday, 6 June 2013 at 17:48:59 UTC, Steven Schveighoffer wrote:
> On Thu, 06 Jun 2013 13:40:37 -0400, Lars T. Kyllingstad <public@kyllingen.net> wrote:
>
>> On Thursday, 6 June 2013 at 17:28:56 UTC, Steven Schveighoffer wrote:
>
>>> Great!  I'd highly suggest pathEqual which takes two ranges of dchar and does the composition and OS-specific comparison for you.
>>
>> They don't have to be dchar if all the building blocks are templates (as the existing ones are):
>>
>> bool pathEqual(CaseSensitive cs = CaseSensitive.osDefault, C1, C2)
>>               (const(C1)[] p1, const(C2)[] p2)
>>     if (isSomeChar!C1 && isSomeChar!C2)
>
> Actually, all string variants are dchar ranges :)  And your solution is less general, dchar ranges don't have to be arrays.

Ok, now I see what you meant.

> However, I don't think in practice there are any real non-array dchar ranges...

At least not any that also support slicing, which I think it is fair to require of "path ranges".

On 6/6/2013 10:50 AM, Jonathan M Davis wrote:
> Some modules have needed been redone. Some still do. But we already _did_
> rework std.path. We agreed that we liked the new API, and it's been working
> great. It's one thing to revisit an API that's been around since before we had
> ranges or a review process. It's an entirely different thing to be constantly
> reworking entire modules. I think that we need _very_ strong justification to
> redesign a module that we already put through the review process. And I really
> don't think that we have it here.

I think we're in violent agreement.

An example of a strong justification for a redo is, for example, conversion to use ranges. std.zip needs that treatment.

On 6/6/2013 10:59 AM, Jonathan M Davis wrote:
> On Thursday, June 06, 2013 10:27:28 Walter Bright wrote:
>> But there's no getting around the fact
>> that "File" and "file" are different paths under Windows, and are the same
>> under Linux.
>
> I think you got that backwards. ;)

Dang, I should have written some unittests!

Just want to chime in and say that I'm also against this change.

I can see some small benefits, but I also see problems, all of which have already been covered.

Even if it is a small net improvement, I don't think it's anywhere near a big enough improvement to warrant an API change.