ndmitchell at gmail.com
Thu Mar 15 15:26:09 EDT 2007
> Of course I can't come up with an elaborate proposal in 5 minutes, but I think
> the main points should be:
> * FilePath is abstract, perhaps even constructed from FilePathElements
> (there are pros and cons for introducing the latter, I'm not totally sure
> about all implications).
> * Explicit operations for constructing and accessing a FilePath are
> * Operations like the ones in your proposal are provided.
In general, I don't see anything wrong with this proposal, but I'm
perfectly happy with the status at the moment. I suspect that people
who do things on FilePath's using the fact that they are String tend
to get it wrong anyway, other than showing them.
Of course, the reverse compatability situation in this case would be a
complete nightmare - possibly bad enough to make it just plain
The upside to adding my System.FilePath module as soon as possible
would be that if people can be slowly weaned off hacking at FilePath's
as String's, then your more drastic change is much more likely to be
acceptable. In addition, if people move to entirely using
System.FilePath then their code would already be portable to your
More information about the Libraries