Hi Colin -

Colin Putney wrote:
> On 21-Nov-09, at 3:22 PM, Andreas Raab wrote:
>> I think you should change the terminology slightly. Having the 
>> implementation specific thing called "path" and the user visible 
>> entity called "reference" is confusing - when I was looking at the 
>> code I saw "oh, there's a path, yeah, that's what I'm looking for". 
>> The term "reference" didn't ring a bell with me. In other words, I 
>> would have users deal with FSPath objects and rename the current 
>> FSPath to something obviously obscure, for example 
>> "FSPathSequenceImpl" or something to make obviously clear that from 
>> the user perspective you're going to deal with the FSPath only.
> 
> Yes. Terminology is both important and difficult. I'm not very happy 
> with the term "reference" either, but I can't think of anything better. 
> The thing I called "path" really is a path, where as "references" are 
> something more than a path. That said, it may be wiser to bow to the 
> intuition of users, even though their intuition is wrong. :-)

Heh. Not saying you have to but then perhaps just making the short (and 
to users very meaningful!) name of "FSPath" be a little less short and 
meaningful might be helpful. Just ask yourself "which class would *I* 
look at first if I read all these names and wanted to figure out what to 
use?". To me, FSPath came clearly before FSReference when we're talking 
about file system stuff.

> I'm not sure I understand the problem with multiple filesystems on 
> Windows. Sure, you stumbled over some exposed girders trying to 
> enumerate the available drives, but that doesn't mean the building isn't 
> structurally sound. 

Oh, don't get me wrong here, I'm not saying it's structurally unsound. 
What I'm saying is that for my practical use the ability to manipulate 
the drive/share in the same namespace that the directory lives in is 
more useful than modeling the underlying DOS semantics precisely.

Speaking from the perspective of the apps that I've actually written, 
precisely none of them cared for those dos current drive and cwd 
semantics, simply because no Windows user interacts with them outside 
the shell (which on Windows practically nobody uses anyway). Even though 
you're able to type 'em into the explorer bar no user does that in 
practice. And even then, the places where you'd have to deal with those 
concepts are in file open / save dialogs where in any real app you use 
the native dialogs anyway (which may or may not support that but it's 
out of your control).

In short, what I'm saying is that I don't know of situation short of 
writing a shell replacement that would require us to support that DOS 
semantics precisely. However, pretty much all of the cross-platform 
stuff I write with regards to file handling depends on being able to 
manipulate drive and share names as part of the filesystem namespace on 
Windows.

I'm simply asking for making it possible to manipulate those names in a 
consistent way. How that is achieved is irrelevant from my perspective - 
if you prefer to do this by a "virtual mount" or something else isn't 
all that important to me.

Cheers,
   - Andreas