Re: Scala IO report on current state of the API implemented by Paul P.

On Thu, Oct 15, 2009 at 7:09 AM, Kevin Wright
wrote:
> i.e. File has-a Path
> and not File is-a Path

This isn't quite right.

At least in the Unix model (which is very close to the NIO model,
unsurprisingly) you interact with (ie. read, write) file system
entities via file descriptors, and whilst these are typically obtained
using a path, they don't have a path intrinsically.

So I think,

Path {
// open the file (if any) denoted by this path
def file : Option[File]

// open the directory (if any) denoted by this path
def directory : Option[Directory]
}

makes sense, but,

File {
// return this File's path
def path : Path
}

doesn't, because the File might by now be associated with no paths or many.

Cheers,

Miles

>
> I think this is a really good example of where something like the DCI
> pattern would be a perfect fit.
> Then we could refer to files and directories as simply being possible
> roles for a path to perform.
>
>> Could all three be siblings of a FileSystemRef abstract class that has those
>> shared methods?
>>
>> Jesse
>
>
>
>> On 2009-10-14, at 20:19, Miles Sabin wrote:
>>
>>> On Wed, Oct 14, 2009 at 6:31 PM, Jesse Eichar wrote:
>>>>
>>>> I agree that there is an inherent race condition but I don't think that
>>>> using only Path helps that in any way.  Consider the equivalent snippet
>>>> when
>>>> are using only path:
>>>>
>>>>
>>>> val p:Path = ...
>>>> if(p.isDirectory) {
>>>> // Filesystem is mutated external an now is denotes a file
>>>>
>>>> // do stuff assuming p is a valid file.
>>>> }
>>>
>>> Well, this isn't quite what I had in mind.
>>>
>>> To be clear, I'm not opposed in principle to the idea of there being
>>> distinct types for files and directories: what I'm opposed to is
>>> either of these extending the path type (which I believe both do
>>> currently).
>>>
>>> The problem with File <: Path and Directory <: Path is that it
>>> encourages the view that a path can be fixed as a file path or
>>> directory path (or a hybrid), and in general, on most filesystems,
>>> that's simply not true.
>>>
>>> If we remove that subtype relationship then we're just fine: the
>>> file/dir (via their underlying OS handles/descriptors) and the path
>>> can go their separate ways.
>>>
>>> So, for your example above, I'd like to see something like,
>>>
>>>  val p : Path = ...
>>>  val optDir = p.directory
>>>  optDir match {
>>>   case Some(d) => // It was a directory, we now have a path-independent
>>> handle
>>>   case None =>
>>>  }
>>>
>>> This is more or less what NIO2 does, with DirectoryStreams for
>>> Directory and {Input,Output}Streams and Channels for File.
>>>
>>> NIO2's Path has a slightly confusingly named FileRef as it's
>>> superclass, but if you look at it closely you'll see that it only
>>> defines path-related methods (ie. attribute access and file handle
>>> creation).
>>>
>>> Cheers,
>>>
>>>
>>> Miles
>>>
>>> --
>>> Miles Sabin
>>> tel: +44 (0)7813 944 528
>>> skype:  milessabin
>>> http://www.chuusai.com/
>>> http://twitter.com/milessabin
>>
>

On Thu, Oct 15, 2009 at 4:43 PM, Jesse Eichar
wrote:
> Could all three be siblings of a FileSystemRef abstract class that has those
> shared methods?

No, they shouldn't be. The things like attributes are related to
paths, not file descriptors.

There really is a reason why the NIO2 API is the shape it is.

Cheers,

Miles

On Thu, Oct 15, 2009 at 8:27 AM, Miles Sabin wrote:
> On Thu, Oct 15, 2009 at 7:09 AM, Kevin Wright
> wrote:
>> i.e. File has-a Path
>> and not File is-a Path
>
> This isn't quite right.
>
> At least in the Unix model (which is very close to the NIO model,
> unsurprisingly) you interact with (ie. read, write) file system
> entities via file descriptors, and whilst these are typically obtained
> using a path, they don't have a path intrinsically.
>
> So I think,
>
>  Path {
>    // open the file (if any) denoted by this path
>    def file : Option[File]
>
>    // open the directory (if any) denoted by this path
>    def directory : Option[Directory]
>  }
>
> makes sense, but,
>
>  File {
>    // return this File's path
>    def path : Path
>  }
>
> doesn't, because the File might by now be associated with no paths or many.
>
> Cheers,
>
>
> Miles
>

I'm not sure if any filesystems actually allow this, but I can then
imagine scenarios such as having a file renamed when it's still open,
I can see how that impacts the design here.

As for multiple paths, I've already had to deal with that one. 8.3 vs
long filenames in windows is a classic example here.
Hard links on unix systems provide a similar can of worms too.

Given the possibility of hard links, I can't see that it's even
possible to even state that a single path should be considered
canonical.

So I can see two possibilities here;
- go for a model where obtaining a file from a path is possible, but
the reverse operation is invalid.
- have properties on a file to show:
a) the path it was opened from (if known) and
b) a list of canonical paths it could have been opened from

>>
>> I think this is a really good example of where something like the DCI
>> pattern would be a perfect fit.
>> Then we could refer to files and directories as simply being possible
>> roles for a path to perform.
>>
>>> Could all three be siblings of a FileSystemRef abstract class that has those
>>> shared methods?
>>>
>>> Jesse
>>
>>
>>
>>> On 2009-10-14, at 20:19, Miles Sabin wrote:
>>>
>>>> On Wed, Oct 14, 2009 at 6:31 PM, Jesse Eichar wrote:
>>>>>
>>>>> I agree that there is an inherent race condition but I don't think that
>>>>> using only Path helps that in any way.  Consider the equivalent snippet
>>>>> when
>>>>> are using only path:
>>>>>
>>>>>
>>>>> val p:Path = ...
>>>>> if(p.isDirectory) {
>>>>> // Filesystem is mutated external an now is denotes a file
>>>>>
>>>>> // do stuff assuming p is a valid file.
>>>>> }
>>>>
>>>> Well, this isn't quite what I had in mind.
>>>>
>>>> To be clear, I'm not opposed in principle to the idea of there being
>>>> distinct types for files and directories: what I'm opposed to is
>>>> either of these extending the path type (which I believe both do
>>>> currently).
>>>>
>>>> The problem with File <: Path and Directory <: Path is that it
>>>> encourages the view that a path can be fixed as a file path or
>>>> directory path (or a hybrid), and in general, on most filesystems,
>>>> that's simply not true.
>>>>
>>>> If we remove that subtype relationship then we're just fine: the
>>>> file/dir (via their underlying OS handles/descriptors) and the path
>>>> can go their separate ways.
>>>>
>>>> So, for your example above, I'd like to see something like,
>>>>
>>>>  val p : Path = ...
>>>>  val optDir = p.directory
>>>>  optDir match {
>>>>   case Some(d) => // It was a directory, we now have a path-independent
>>>> handle
>>>>   case None =>
>>>>  }
>>>>
>>>> This is more or less what NIO2 does, with DirectoryStreams for
>>>> Directory and {Input,Output}Streams and Channels for File.
>>>>
>>>> NIO2's Path has a slightly confusingly named FileRef as it's
>>>> superclass, but if you look at it closely you'll see that it only
>>>> defines path-related methods (ie. attribute access and file handle
>>>> creation).
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> Miles
>>>>
>>>> --
>>>> Miles Sabin
>>>> tel: +44 (0)7813 944 528
>>>> skype:  milessabin
>>>> http://www.chuusai.com/
>>>> http://twitter.com/milessabin
>>>
>>
>
>
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

On Thu, Oct 15, 2009 at 9:25 AM, Kevin Wright
wrote:
> I'm not sure if any filesystems actually allow this, but I can then
> imagine scenarios such as having a file renamed when it's still open,
> I can see how that impacts the design here.

All Unix-like filesystems (that I'm aware of) allow that.

Hard links on many filesystems allow a single filesystem entity to be
reachable via many paths, each of which might have different
permissions associated with it.

Unix-like filesystems also support unlinking of paths (in effect
deletion, from the filesystems POV) associated with an open file
descriptor ... the underlying storage is reclaimed when there are no
remaining hard links or open descriptors (there are many classic Unix
programming techniques which depend on this behaviour).

Cheers,

Miles

I think I'd prefer if Path had no knowledge of Files or Directories

On Thu, Oct 15, 2009 at 10:33 AM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Oct 15, 2009 at 9:25 AM, Kevin Wright
<kev.lee.wright@googlemail.com> wrote:
> I'm not sure if any filesystems actually allow this, but I can then
> imagine scenarios such as having a file renamed when it's still open,
> I can see how that impacts the design here.

All Unix-like filesystems (that I'm aware of) allow that.

Hard links on many filesystems allow a single filesystem entity to be
reachable via many paths, each of which might have different
permissions associated with it.

Unix-like filesystems also support unlinking of paths (in effect
deletion, from the filesystems POV) associated with an open file
descriptor ... the underlying storage is reclaimed when there are no
remaining hard links or open descriptors (there are many classic Unix
programming techniques which depend on this behaviour).

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

On Thu, 15 Oct 2009 09:33:27 +0100, Miles Sabin wrote:
[...]
> Hard links on many filesystems allow a single filesystem entity to be
> reachable via many paths, each of which might have different
> permissions associated with it.

A very minor nitpick/clarification. Permissions in POSIX-like filesystems are
associated with the file, not its directory entry. So the above is true
if read as noticing that the intermediate directories on the different paths
may have different permissions. But the file itself has the same
permission bits independently of the path used to access it.

2009/10/15 Michal Politowski :
> On Thu, 15 Oct 2009 09:33:27 +0100, Miles Sabin wrote:
> [...]
>> Hard links on many filesystems allow a single filesystem entity to be
>> reachable via many paths, each of which might have different
>> permissions associated with it.
>
> A very minor nitpick/clarification. Permissions in POSIX-like filesystems are
> associated with the file, not its directory entry. So the above is true
> if read as noticing that the intermediate directories on the different paths
> may have different permissions. But the file itself has the same
> permission bits independently of the path used to access it.

Nitpick accepted.

What I was really pointing to is that permissions are not associated
with file descriptors which are the things which File/Directory
correspond to.

Cheers,

Miles

Cheers,

Miles

How have you've imagined the API usage?

Something like?

Host fileSystem resolve(Path(".")) match {
  case f : File =>
  case d : Directory =>
  case _ => sad_face
}

2009/10/15 Michal Politowski <2Bscala [at] meep [dot] pl" rel="nofollow">mpol+scala@meep.pl>

On Thu, 15 Oct 2009 09:33:27 +0100, Miles Sabin wrote:
[...]
> Hard links on many filesystems allow a single filesystem entity to be
> reachable via many paths, each of which might have different
> permissions associated with it.

A very minor nitpick/clarification. Permissions in POSIX-like filesystems are
associated with the file, not its directory entry. So the above is true
if read as noticing that the intermediate directories on the different paths
may have different permissions. But the file itself has the same
permission bits independently of the path used to access it.

--
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

2009/10/15 Viktor Klang :
> How have you've imagined the API usage?
>
> Something like?
>
> Host fileSystem resolve(Path(".")) match {
>   case f : File =>
>   case d : Directory =>
>   case _ => sad_face
> }

Hopefully we can make the typical case terser than that. Assuming
something like this,

trait Handle {
def asFile : File // Default impl always fails
def asDirectory : Directory // Default impl always fails
}

object NoHandle extends Handle

trait File {
override def asFile = this
}

trait Dir {
override def asDirectory = this
}

In which case we could have,

val f = Path(".") open(R|W) asFile
// do stuff with f

If you care about handling the failure cases you'd have,

Path(".") open(R|W) match {
case f : File => // do stuff with f
case _ => // fail
}

Cheers,

Miles

On Thursday October 15 2009, Michal Politowski wrote:
> On Thu, 15 Oct 2009 09:33:27 +0100, Miles Sabin wrote:
> [...]
>
> > Hard links on many filesystems allow a single filesystem entity to
> > be reachable via many paths, each of which might have different
> > permissions associated with it.
>
> A very minor nitpick/clarification. Permissions in POSIX-like
> filesystems are associated with the file, not its directory entry. So
> the above is true if read as noticing that the intermediate
> directories on the different paths may have different permissions.
> But the file itself has the same permission bits independently of the
> path used to access it.

True, but the accessing user (ID) must have execute permission on each
directory mentioned in the path name. Directory execute permissions are
interpreted as "permission to scan during path-name resolution."

Randall Schulz

On Thu, Oct 15, 2009 at 1:47 PM, Miles Sabin <miles@milessabin.com> wrote:

2009/10/15 Viktor Klang <viktor.klang@gmail.com>:
> How have you've imagined the API usage?
>
> Something like?
>
> Host fileSystem resolve(Path(".")) match {
>   case f : File =>
>   case d : Directory =>
>   case _ => sad_face
> }

Hopefully we can make the typical case terser than that. Assuming
something like this,

def file(p : Path) = Host fileSystem resolve(p) match {
                                   case f : File => Some(f)
                                   case _ => None
                              }
 

 trait Handle {
   def asFile : File // Default impl always fails
   def asDirectory : Directory // Default impl always fails
 }

 object NoHandle extends Handle

 trait File {
   override def asFile = this
 }

 trait Dir {
   override def asDirectory = this
 }

In which case we could have,

 val f = Path(".") open(R|W) asFile
 // do stuff with f

If you care about handling the failure cases you'd have,

 Path(".") open(R|W) match {
   case f : File => // do stuff with f
   case _ => // fail
 }

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

On Thu, Oct 15, 2009 at 3:21 PM, Viktor Klang wrote:
> def file(p : Path) = Host fileSystem resolve(p) match {
>                                    case f : File => Some(f)
>                                    case _ => None
>                               }

I'm not sure if you're just sketching or offering something concrete
... my apologies for taking this too seriously if it's the former.

"resolve" doesn't work if it doesn't involve actually obtaining a file
descriptor, in which case it should really be called "open" and
require a mode.

If you're intending that this doesn't do an open, but returns
something Path-like, and fixed as a path which is guaranteed to denote
a file, then could you please reread this thread for an explanation of
why that doesn't work.

Other than that, I think I'd prefer to see host components
incorporated into that path abstraction.

Cheers,

Miles

On 15 Oct 2009, at 09:25, Kevin Wright wrote:
> As for multiple paths, I've already had to deal with that one. 8.3 vs
> long filenames in windows is a classic example here.
> Hard links on unix systems provide a similar can of worms too.
>
> Given the possibility of hard links, I can't see that it's even
> possible to even state that a single path should be considered
> canonical.

Hard links are actually separate paths; it's just that on-disk, the
bits are stored in the same place.

A file always has a canonical path, but there may also be many paths
that point to the same file. Even without symlinks, /tmp/foo may be /
tmp/bar/../foo, /tmp/bar/../git/../foo and so forth. However, there's
always the canonical representation. Disallowing the ability to get
the canonical path from the file would be a bad move.

Secondly, when obtaining a file from a path, there's also that path -
the one that you used to open a file on. So if I open a file /tmp/FOO
and then later on open /tmp/foo, they could refer to the same file (if
the file system is non-case sensitive) but I'd need the ability, from
a UI perpsective, to be able to prompt the user for the non-canonical,
what they first asked for, filename. In other words, File from "/tmp/
FOO" name -> FOO but File from "/tmp/foo" name -> foo.

So, multiple paths can resolve to the same file. Each file has two
paths; the one that was asked for when it opened, and a canonical
representation of the same, where canonicalisation resolves soft (but
not hard) links, directory changes and the like. (The directory
changes really should be a filesystem specific operation rather than
in File though; not all filesystems will have the concept of '..' as a
parent directory.)

NB for hard links, /tmp/a and /tmp/b, both pointing to /tmp/foo, there
are actually 3 files, /tmp/a, /tmp/b and /tmp/foo. We can't (and
shouldn't) be able to differ between a hard link and a regular file;
in part, because a regular file is a hard linked file with no other
links, and the two are interchangable (a file can become a hard linked
file by virtue of someone else hard linking; it can also go from hard
linking to being a regular file if the other hard link is removed).

> So I can see two possibilities here;
> - go for a model where obtaining a file from a path is possible, but
> the reverse operation is invalid.
> - have properties on a file to show:
> a) the path it was opened from (if known) and
> b) a list of canonical paths it could have been opened from

I think b opens a can of worms. What happens with case-insensitive
file systems? Any of those might be possible too. What about files
opened over WebDAV which might have multiple hosts referring to the
same file? Given that 'canonical' means 'authoratitive', how can any
two be authoratitve? Surely this is a case of there being multiple
paths (long and 8.3) but only one of them need be canonical (long). A
win-32 specific munger might be able to do the long-short conversion,
but it shouldn't be part of the File API.

Alex

On Thursday October 15 2009, Alex Blewitt wrote:
> ...
>
> NB for hard links, /tmp/a and /tmp/b, both pointing to /tmp/foo,
> there are actually 3 files, /tmp/a, /tmp/b and /tmp/foo.

No, that's one file with three names.

> We can't
> (and shouldn't) be able to differ between a hard link and a regular
> file;

There simply is no such distinction. All hard links for a file are
coequal. The fact that one came first is of no consequence whatsoever.

> in part, because a regular file is a hard linked file with no
> other links, and the two are interchangable (a file can become a hard
> linked file by virtue of someone else hard linking; it can also go
> from hard linking to being a regular file if the other hard link is
> removed).

You're misunderstanding the nature of the Unix file system. There are
files, identified by a number distinct only within a given file system
volume. Then there is a directory tree that associates names (one or
more) with those low-level, numeric identifiers. Apart from transient
conditions when a file is in use but has no names, all files have at
least one hard link.

Symbolic links are different, of course. They're a special kind of file
(that holds a little bit of text) that (potentially) refers to another
file system entity. They can refer to non-existent files. They can also
cross file system boundaries (not possible with a hard link).

> ...
>
> Alex

Randall Schulz

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path          /     \        /         \FilePath   DirectoryPath    To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file     <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource     <> -- OutputStreamResource     <> -- FileChannelResource     <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are:* Obviously there is great confusion as shown in this thread* Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

Hi,
On Oct 18, 2009, at 18:42, Jesse Eichar wrote:

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path          /     \        /         \FilePath   DirectoryPath    To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file     <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource     <> -- OutputStreamResource     <> -- FileChannelResource     <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are:* Obviously there is great confusion as shown in this thread* Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

I managed to go through this thread just now, and in a bit of a hurry I admit. But I am aware of thew whole Scala I/O process going on.
My thoughts have been very clear from the beginning that I saw the new Java Path API: They get it wrong once more. The reason the JDK folks get this wrong, IMHO, is because they do not separate concerns. It is one thing to have a _name_ for an object and a completely different thing to have the object (or an idea of what the object stands for).
A Path has nothing to do with any underlying resource data or metadata, besides the fact that is shows the way to obtain them. And of course, it inherits any naming non-uniformity/ugliness of the underlying OS (Windows is the champion here).
A Path should be an immutable, type-full representative for a (composite) name with some extra algebraic properties (semigroup for sure, monoid in principle) with the "/" operator playing the obvious role.
If you insist on semantically handling the Path the way it is now, please give it another name. What JDK 7 has as Path is not a path at all. 
BR,Christos -- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

On Sun, Oct 18, 2009 at 4:42 PM, Jesse Eichar wrote:
> Does this sound like a plan?

It does :-)

> Could someone please create a ScalaIO repository in the incubator github
> project for me and add jesseeichar as a collaborator?  I have my code in my
> personal repo but only temporarily until I can put in the incubator.

Done.

Cheers,

Miles

On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:

Hi,
On Oct 18, 2009, at 18:42, Jesse Eichar wrote:

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path          /     \        /         \FilePath   DirectoryPath     To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file     <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource     <> -- OutputStreamResource     <> -- FileChannelResource     <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are:* Obviously there is great confusion as shown in this thread* Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

I managed to go through this thread just now, and in a bit of a hurry I admit. But I am aware of thew whole Scala I/O process going on.
My thoughts have been very clear from the beginning that I saw the new Java Path API: They get it wrong once more. The reason the JDK folks get this wrong, IMHO, is because they do not separate concerns. It is one thing to have a _name_ for an object and a completely different thing to have the object (or an idea of what the object stands for).
A Path has nothing to do with any underlying resource data or metadata, besides the fact that is shows the way to obtain them. And of course, it inherits any naming non-uniformity/ugliness of the underlying OS (Windows is the champion here).
A Path should be an immutable, type-full representative for a (composite) name with some extra algebraic properties (semigroup for sure, monoid in principle) with the "/" operator playing the obvious role.

Also, the object residing at that Path can change willy-nillingly from underneath.
 

If you insist on semantically handling the Path the way it is now, please give it another name. What JDK 7 has as Path is not a path at all. 
BR,Christos -- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

Hi Christos and Viktor,

I think I understand your point (I hope so) and I would love to have a Path that is independent from a filesystem,  but the problem is that I am not an expert in the field of filesystems.  I have naturally used Linux, OSX, windows and some other minor variants but I have never made a study of them.  Therefore I do not feel qualified to be able to determine the consequences of making such a change.  A couple of easy examples issues that need to be solved are:

How to represent roots in a Path object.  IE.  How could you define a generic path for windows and Linux.  Do you do something like cygwin: /c/.  But that is clearly windows dependent now and would not work on a linux box.  (Probably not a big issue)

If we declare / to be the seperator how would we handle filesystems where / is a valid character for directory or file names.  Obviously we could add escape characters.

Point is I came up with those issue without even thinking more than 39 seconds on the issue.  I am sure there are many issues that I am overlooking and I would rather have a functional but unpleasant API than a completely broken API. 

However feel free to call me an idiot and tell me why I am wrong.

Jesse

On Mon, Oct 19, 2009 at 1:15 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:

Hi,
On Oct 18, 2009, at 18:42, Jesse Eichar wrote:

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path          /     \        /         \FilePath   DirectoryPath     To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file     <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource     <> -- OutputStreamResource     <> -- FileChannelResource     <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are:* Obviously there is great confusion as shown in this thread* Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

I managed to go through this thread just now, and in a bit of a hurry I admit. But I am aware of thew whole Scala I/O process going on.
My thoughts have been very clear from the beginning that I saw the new Java Path API: They get it wrong once more. The reason the JDK folks get this wrong, IMHO, is because they do not separate concerns. It is one thing to have a _name_ for an object and a completely different thing to have the object (or an idea of what the object stands for).
A Path has nothing to do with any underlying resource data or metadata, besides the fact that is shows the way to obtain them. And of course, it inherits any naming non-uniformity/ugliness of the underlying OS (Windows is the champion here).
A Path should be an immutable, type-full representative for a (composite) name with some extra algebraic properties (semigroup for sure, monoid in principle) with the "/" operator playing the obvious role.

Also, the object residing at that Path can change willy-nillingly from underneath.
 

If you insist on semantically handling the Path the way it is now, please give it another name. What JDK 7 has as Path is not a path at all. 
BR,Christos -- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

Repository pushed to Github.  http://wiki.github.com/scala-incubator/scala-io

Nowhere near complete or useable but you have to start somewhere. 

Jesse

On Mon, Oct 19, 2009 at 12:52 AM, Miles Sabin <miles@milessabin.com> wrote:

On Sun, Oct 18, 2009 at 4:42 PM, Jesse Eichar <jeichar.w@gmail.com> wrote:
> Does this sound like a plan?

It does :-)

> Could someone please create a ScalaIO repository in the incubator github
> project for me and add jesseeichar as a collaborator?  I have my code in my
> personal repo but only temporarily until I can put in the incubator.

Done.

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Just chiming in to suggest that the problem with representing roots and path separator could maybe be solved by using URI. The path class would expose both the general representation as URI and the native representation as OS specific path (based on the file system pointed to by the path or specified at creation). Internally, URI will always be used to do operations such as joining paths, etc.

I never had to design a file system API myself, but as a user of many such APIs, it is something I am long wishing for. It would also help merge representation of a local path with an URL.
Sébastien
On Mon, Oct 19, 2009 at 19:15, Jesse Eichar <jeichar.w@gmail.com> wrote:

Hi Christos and Viktor,

I think I understand your point (I hope so) and I would love to have a Path that is independent from a filesystem,  but the problem is that I am not an expert in the field of filesystems.  I have naturally used Linux, OSX, windows and some other minor variants but I have never made a study of them.  Therefore I do not feel qualified to be able to determine the consequences of making such a change.  A couple of easy examples issues that need to be solved are:

How to represent roots in a Path object.  IE.  How could you define a generic path for windows and Linux.  Do you do something like cygwin: /c/.  But that is clearly windows dependent now and would not work on a linux box.  (Probably not a big issue)

If we declare / to be the seperator how would we handle filesystems where / is a valid character for directory or file names.  Obviously we could add escape characters.

Point is I came up with those issue without even thinking more than 39 seconds on the issue.  I am sure there are many issues that I am overlooking and I would rather have a functional but unpleasant API than a completely broken API. 

However feel free to call me an idiot and tell me why I am wrong.

Jesse

On Mon, Oct 19, 2009 at 1:15 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:

Hi,
On Oct 18, 2009, at 18:42, Jesse Eichar wrote:

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path          /     \        /         \FilePath   DirectoryPath     To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file     <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource     <> -- OutputStreamResource     <> -- FileChannelResource     <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are:* Obviously there is great confusion as shown in this thread* Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

I managed to go through this thread just now, and in a bit of a hurry I admit. But I am aware of thew whole Scala I/O process going on.
My thoughts have been very clear from the beginning that I saw the new Java Path API: They get it wrong once more. The reason the JDK folks get this wrong, IMHO, is because they do not separate concerns. It is one thing to have a _name_ for an object and a completely different thing to have the object (or an idea of what the object stands for).
A Path has nothing to do with any underlying resource data or metadata, besides the fact that is shows the way to obtain them. And of course, it inherits any naming non-uniformity/ugliness of the underlying OS (Windows is the champion here).
A Path should be an immutable, type-full representative for a (composite) name with some extra algebraic properties (semigroup for sure, monoid in principle) with the "/" operator playing the obvious role.

Also, the object residing at that Path can change willy-nillingly from underneath.
 

If you insist on semantically handling the Path the way it is now, please give it another name. What JDK 7 has as Path is not a path at all. 
BR,Christos -- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

Hi Jesse,   On Tue, Oct 20, 2009 at 02:15, Jesse Eichar <jeichar.w@gmail.com> wrote:

Hi Christos and Viktor,

I think I understand your point (I hope so) and I would love to have a Path that is independent from a filesystem,  but the problem is that I am not an expert in the field of filesystems.  I have naturally used Linux, OSX, windows and some other minor variants but I have never made a study of them.  Therefore I do not feel qualified to be able to determine the consequences of making such a change.  A couple of easy examples issues that need to be solved are:

How to represent roots in a Path object.  IE.  How could you define a generic path for windows and Linux.  Do you do something like cygwin: /c/.  But that is clearly windows dependent now and would not work on a linux box.  (Probably not a big issue)

If we declare / to be the seperator how would we handle filesystems where / is a valid character for directory or file names.  Obviously we could add escape characters.

Point is I came up with those issue without even thinking more than 39 seconds on the issue.  I am sure there are many issues that I am overlooking and I would rather have a functional but unpleasant API than a completely broken API. 

However feel free to call me an idiot and tell me why I am wrong.

Jesse

  Never, never say "I could be an idiot" when putting forward constructive thoughts. I go by the motto "I think, therefore I live", although I am pretty sure someone else has said that first. You may have seen me "thinking aloud" a few times in the lists as well.   Now, to the point. I think there is a critical observation that can cast most of the difficulties away: Paths are not OS-transferable. You cannot serialize a Windows path, then deserialize it in Unix and play by the same semantics. It does not work. You can prove this by a counter-example: "C:\" has very special meaning in Windows, but nothing special in Unix. So, this liberates us to work out the several cases separately.   I could post more on this, if you like, but I am running like hell right now, making the final preparations for the book. Actually the only reason I did not get actively involved into the Scala IO thing is purely lack of time, not lack of intereset (on the contrary, as I have thought and worked a bit about the relevant issues).    

On Mon, Oct 19, 2009 at 1:15 AM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos <loverdos@gmail.com> wrote:

Hi,
On Oct 18, 2009, at 18:42, Jesse Eichar wrote:

Hi,
I have been reading the last batch of emails about the File-Directory-Path split with great interest.  First of all I believe that there is a misunderstanding about the role of File and Directory.  File is in no way a FileHandle or FileDescriptor.  It is probably better described as FilePath.  IE a Path that is assumed by the programmer to reference an existing file or not yet exist (and be used to create the File).
But that is mostly moot because I have been writing some code samples that uses the API and I have decided that the split offers only a very slight advantage over just having Path.  
So I am now leaning towards not having Path-File-Directory and instead having a Path and very clean semantics for opening files and directories and operating on them.  I am in the midst of refactoring the code from File and Directory into Path.  However for this first draft I am minimizing the number convenience methods and keeping the API as simple as possible.  In fact until I have time to review the ARM project I am not even going to provide read/write access to files.  I will just add the placeholders openFile and openDirectory.
So to recap I am looking at moving from:
           Path           /     \         /         \ FilePath   DirectoryPath      To something like (I need to review the ARM work being done because the API will depend on that work)
Path <> -- FileResource    // provides access to file      <> -- DirectoryStream // See NIO directory stream (but scalified)
or maybe 
Path <> -- InputStreamResource      <> -- OutputStreamResource      <> -- FileChannelResource      <> -- DirectoryStream     // See NIO directory stream
(Details will be forth coming :))
The reasons for going with this style architecture are: * Obviously there is great confusion as shown in this thread * Having FilePath and DirectoryPath makes certain common operations on File and Directory a little confusing.  (I have made several code examples comparing the two and have seen very little benefit to the FilePath architecture)
Does this sound like a plan?
Could someone please create a ScalaIO repository in the incubator github project for me and add jesseeichar as a collaborator?  I have my code in my personal repo but only temporarily until I can put in the incubator.  
Jesse 

I managed to go through this thread just now, and in a bit of a hurry I admit. But I am aware of thew whole Scala I/O process going on.
My thoughts have been very clear from the beginning that I saw the new Java Path API: They get it wrong once more. The reason the JDK folks get this wrong, IMHO, is because they do not separate concerns. It is one thing to have a _name_ for an object and a completely different thing to have the object (or an idea of what the object stands for).
A Path has nothing to do with any underlying resource data or metadata, besides the fact that is shows the way to obtain them. And of course, it inherits any naming non-uniformity/ugliness of the underlying OS (Windows is the champion here).
A Path should be an immutable, type-full representative for a (composite) name with some extra algebraic properties (semigroup for sure, monoid in principle) with the "/" operator playing the obvious role.

Also, the object residing at that Path can change willy-nillingly from underneath.
 

If you insist on semantically handling the Path the way it is now, please give it another name. What JDK 7 has as Path is not a path at all. 
BR, Christos -- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang
Wave: viktor.klang@googlewave.com
Code: github.com/viktorklang

AKKA Committer - akkasource.org
Lift Committer - liftweb.com
Atmosphere Committer - atmosphere.dev.java.net
SoftPub founder: http://groups.google.com/group/softpub

    BR Christos.

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

More and more, it's looking like we should just treat paths as URIs

How about then offering a WindowsPath and UnixPath as
functions/extractors over thus underlying representation, to allow
treating paths in a more human-friendly manner?

i.e.

path : Path = WindowsPath("""c:\my\file.ext""")
path2 : Path = UnixPath("/my/file.ext")

path match {
case WindowsPath("""c:\my\file.ext""") => ...
case UnixPath("/my/file.ext") => ...
}

path match {
case WindowsPath(pathstr) => println("windows path =" + pathstr)
case UnixPath(pathstr) => println("unix path =" + pathstr)
}

The extractors could even handle wildcards, globbing, ~ for home
directories, etc.

apply() on the Path singleton would also need to infer the kind of
path it's working with and then convert to an underlying "file://..."
representation
Plus we'd need separate methods to return the path as either a
canonical URL or as the appropriate system representation. My
personal vote would be to use the system-specific in toString()

On Tue, Oct 20, 2009 at 8:51 AM, Christos KK Loverdos
wrote:
> Hi Jesse,
>
> On Tue, Oct 20, 2009 at 02:15, Jesse Eichar wrote:
>>
>> Hi Christos and Viktor,
>>
>> I think I understand your point (I hope so) and I would love to have a
>> Path that is independent from a filesystem,  but the problem is that I am
>> not an expert in the field of filesystems.  I have naturally used Linux,
>> OSX, windows and some other minor variants but I have never made a study of
>> them.  Therefore I do not feel qualified to be able to determine the
>> consequences of making such a change.  A couple of easy examples issues that
>> need to be solved are:
>>
>> How to represent roots in a Path object.  IE.  How could you define a
>> generic path for windows and Linux.  Do you do something like cygwin: /c/.
>> But that is clearly windows dependent now and would not work on a linux
>> box.  (Probably not a big issue)
>>
>> If we declare / to be the seperator how would we handle filesystems where
>> / is a valid character for directory or file names.  Obviously we could add
>> escape characters.
>>
>> Point is I came up with those issue without even thinking more than 39
>> seconds on the issue.  I am sure there are many issues that I am overlooking
>> and I would rather have a functional but unpleasant API than a completely
>> broken API.
>>
>> However feel free to call me an idiot and tell me why I am wrong.
>>
>> Jesse
>
>
> Never, never say "I could be an idiot" when putting forward constructive
> thoughts. I go by the motto "I think, therefore I live", although I am
> pretty sure someone else has said that first. You may have seen me "thinking
> aloud" a few times in the lists as well.
>
> Now, to the point. I think there is a critical observation that can cast
> most of the difficulties away: Paths are not OS-transferable. You cannot
> serialize a Windows path, then deserialize it in Unix and play by the same
> semantics. It does not work. You can prove this by a counter-example: "C:\"
> has very special meaning in Windows, but nothing special in Unix. So, this
> liberates us to work out the several cases separately.
>
> I could post more on this, if you like, but I am running like hell right
> now, making the final preparations for the book. Actually the only reason I
> did not get actively involved into the Scala IO thing is purely lack of
> time, not lack of intereset (on the contrary, as I have thought and worked a
> bit about the relevant issues).
>
>
>>
>> On Mon, Oct 19, 2009 at 1:15 AM, Viktor Klang
>> wrote:
>>>
>>>
>>> On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos
>>> wrote:
>>>>
>>>> Hi,
>>>> On Oct 18, 2009, at 18:42, Jesse Eichar wrote:
>>>>
>>>> Hi,
>>>> I have been reading the last batch of emails about the
>>>> File-Directory-Path split with great interest.  First of all I believe that
>>>> there is a misunderstanding about the role of File and Directory.  File is
>>>> in no way a FileHandle or FileDescriptor.  It is probably better described
>>>> as FilePath.  IE a Path that is assumed by the programmer to reference an
>>>> existing file or not yet exist (and be used to create the File).
>>>> But that is mostly moot because I have been writing some code samples
>>>> that uses the API and I have decided that the split offers only a very
>>>> slight advantage over just having Path.
>>>> So I am now leaning towards not having Path-File-Directory and instead
>>>> having a Path and very clean semantics for opening files and directories and
>>>> operating on them.  I am in the midst of refactoring the code from File and
>>>> Directory into Path.  However for this first draft I am minimizing the
>>>> number convenience methods and keeping the API as simple as possible.  In
>>>> fact until I have time to review the ARM project I am not even going to
>>>> provide read/write access to files.  I will just add the placeholders
>>>> openFile and openDirectory.
>>>> So to recap I am looking at moving from:
>>>>            Path
>>>>           /     \
>>>>         /         \
>>>> FilePath   DirectoryPath
>>>>
>>>> To something like (I need to review the ARM work being done because the
>>>> API will depend on that work)
>>>> Path <> -- FileResource    // provides access to file
>>>>      <> -- DirectoryStream // See NIO directory stream (but scalified)
>>>> or maybe
>>>> Path <> -- InputStreamResource
>>>>      <> -- OutputStreamResource
>>>>      <> -- FileChannelResource
>>>>      <> -- DirectoryStream     // See NIO directory stream
>>>> (Details will be forth coming :))
>>>> The reasons for going with this style architecture are:
>>>> * Obviously there is great confusion as shown in this thread
>>>> * Having FilePath and DirectoryPath makes certain common operations on
>>>> File and Directory a little confusing.  (I have made several code examples
>>>> comparing the two and have seen very little benefit to the FilePath
>>>> architecture)
>>>> Does this sound like a plan?
>>>> Could someone please create a ScalaIO repository in the incubator github
>>>> project for me and add jesseeichar as a collaborator?  I have my code in my
>>>> personal repo but only temporarily until I can put in the incubator.
>>>> Jesse
>>>>
>>>> I managed to go through this thread just now, and in a bit of a hurry I
>>>> admit. But I am aware of thew whole Scala I/O process going on.
>>>> My thoughts have been very clear from the beginning that I saw the new
>>>> Java Path API: They get it wrong once more. The reason the JDK folks get
>>>> this wrong, IMHO, is because they do not separate concerns. It is one thing
>>>> to have a _name_ for an object and a completely different thing to have the
>>>> object (or an idea of what the object stands for).
>>>> A Path has nothing to do with any underlying resource data or metadata,
>>>> besides the fact that is shows the way to obtain them. And of course, it
>>>> inherits any naming non-uniformity/ugliness of the underlying OS (Windows is
>>>> the champion here).
>>>> A Path should be an immutable, type-full representative for a
>>>> (composite) name with some extra algebraic properties (semigroup for sure,
>>>> monoid in principle) with the "/" operator playing the obvious role.
>>>
>>> Also, the object residing at that Path can change willy-nillingly from
>>> underneath.
>>>
>>>>
>>>> If you insist on semantically handling the Path the way it is now,
>>>> please give it another name. What JDK 7 has as Path is not a path at all.
>>>> BR,
>>>> Christos
>>>> --
>>>>    __~O
>>>>   -\ <,       Christos KK Loverdos
>>>> (*)/ (*)      http://ckkloverdos.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>>
>>> Blog: klangism.blogspot.com
>>> Twttr: viktorklang
>>> Wave: viktor.klang@googlewave.com
>>> Code: github.com/viktorklang
>>>
>>> AKKA Committer - akkasource.org
>>> Lift Committer - liftweb.com
>>> Atmosphere Committer - atmosphere.dev.java.net
>>> SoftPub founder: http://groups.google.com/group/softpub
>>
>
>
>
> BR
> Christos.
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>

Guys, stand back. Take a deep breath.   A file/directory API has a main goal, one responsible for 99%+ of its expected usage: dealing with files and directories on Windows and Unix. The fact that there are many variations on the theme on uncommon operating systems is of very, very little relevant. In fact, I'm much more concerned about volumes on big iron than with other unusual things talked about here.   The use case is to open and close files, read, write, position and truncate them. List files in a directory. Create, delete, rename and move files and directories. Identify whether you have permissions for doing it, and identify if something can be treated as a file or as a directory. And, in all that, use user input to identify them, and display them back to the user, in a system-dependent manner (just like locales).   So, whatever you do, make sure THAT is easy. If necessary, make the rest complex.
On Tue, Oct 20, 2009 at 6:33 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

More and more, it's looking like we should just treat paths as URIs

How about then offering a WindowsPath and UnixPath as
functions/extractors over thus underlying representation, to allow
treating paths in a more human-friendly manner?

i.e.

path : Path = WindowsPath("""c:\my\file.ext""")
path2 : Path = UnixPath("/my/file.ext")


path match {
 case WindowsPath("""c:\my\file.ext""") => ...
 case UnixPath("/my/file.ext") => ...
}

path match {
 case WindowsPath(pathstr) => println("windows path =" + pathstr)
 case UnixPath(pathstr) => println("unix path =" + pathstr)
}


The extractors could even handle wildcards, globbing, ~ for home
directories, etc.

apply() on the Path singleton would also need to infer the kind of
path it's working with and then convert to an underlying "file://..."
representation
Plus we'd need separate methods to return the path as either a
canonical URL or as the appropriate system representation.  My
personal vote would be to use the system-specific in toString()


On Tue, Oct 20, 2009 at 8:51 AM, Christos KK Loverdos
<loverdos@gmail.com> wrote:
> Hi Jesse,
>
> On Tue, Oct 20, 2009 at 02:15, Jesse Eichar <jeichar.w@gmail.com> wrote:
>>
>> Hi Christos and Viktor,
>>
>> I think I understand your point (I hope so) and I would love to have a
>> Path that is independent from a filesystem,  but the problem is that I am
>> not an expert in the field of filesystems.  I have naturally used Linux,
>> OSX, windows and some other minor variants but I have never made a study of
>> them.  Therefore I do not feel qualified to be able to determine the
>> consequences of making such a change.  A couple of easy examples issues that
>> need to be solved are:
>>
>> How to represent roots in a Path object.  IE.  How could you define a
>> generic path for windows and Linux.  Do you do something like cygwin: /c/.
>> But that is clearly windows dependent now and would not work on a linux
>> box.  (Probably not a big issue)
>>
>> If we declare / to be the seperator how would we handle filesystems where
>> / is a valid character for directory or file names.  Obviously we could add
>> escape characters.
>>
>> Point is I came up with those issue without even thinking more than 39
>> seconds on the issue.  I am sure there are many issues that I am overlooking
>> and I would rather have a functional but unpleasant API than a completely
>> broken API.
>>
>> However feel free to call me an idiot and tell me why I am wrong.
>>
>> Jesse
>
>
> Never, never say "I could be an idiot" when putting forward constructive
> thoughts. I go by the motto "I think, therefore I live", although I am
> pretty sure someone else has said that first. You may have seen me "thinking
> aloud" a few times in the lists as well.
>
> Now, to the point. I think there is a critical observation that can cast
> most of the difficulties away: Paths are not OS-transferable. You cannot
> serialize a Windows path, then deserialize it in Unix and play by the same
> semantics. It does not work. You can prove this by a counter-example: "C:\"
> has very special meaning in Windows, but nothing special in Unix. So, this
> liberates us to work out the several cases separately.
>
> I could post more on this, if you like, but I am running like hell right
> now, making the final preparations for the book. Actually the only reason I
> did not get actively involved into the Scala IO thing is purely lack of
> time, not lack of intereset (on the contrary, as I have thought and worked a
> bit about the relevant issues).
>
>
>>
>> On Mon, Oct 19, 2009 at 1:15 AM, Viktor Klang <viktor.klang@gmail.com>
>> wrote:
>>>
>>>
>>> On Sun, Oct 18, 2009 at 8:29 PM, Christos KK Loverdos
>>> <loverdos@gmail.com> wrote:
>>>>
>>>> Hi,
>>>> On Oct 18, 2009, at 18:42, Jesse Eichar wrote:
>>>>
>>>> Hi,
>>>> I have been reading the last batch of emails about the
>>>> File-Directory-Path split with great interest.  First of all I believe that
>>>> there is a misunderstanding about the role of File and Directory.  File is
>>>> in no way a FileHandle or FileDescriptor.  It is probably better described
>>>> as FilePath.  IE a Path that is assumed by the programmer to reference an
>>>> existing file or not yet exist (and be used to create the File).
>>>> But that is mostly moot because I have been writing some code samples
>>>> that uses the API and I have decided that the split offers only a very
>>>> slight advantage over just having Path.
>>>> So I am now leaning towards not having Path-File-Directory and instead
>>>> having a Path and very clean semantics for opening files and directories and
>>>> operating on them.  I am in the midst of refactoring the code from File and
>>>> Directory into Path.  However for this first draft I am minimizing the
>>>> number convenience methods and keeping the API as simple as possible.  In
>>>> fact until I have time to review the ARM project I am not even going to
>>>> provide read/write access to files.  I will just add the placeholders
>>>> openFile and openDirectory.
>>>> So to recap I am looking at moving from:
>>>>            Path
>>>>           /     \
>>>>         /         \
>>>> FilePath   DirectoryPath
>>>>
>>>> To something like (I need to review the ARM work being done because the
>>>> API will depend on that work)
>>>> Path <> -- FileResource    // provides access to file
>>>>      <> -- DirectoryStream // See NIO directory stream (but scalified)
>>>> or maybe
>>>> Path <> -- InputStreamResource
>>>>      <> -- OutputStreamResource
>>>>      <> -- FileChannelResource
>>>>      <> -- DirectoryStream     // See NIO directory stream
>>>> (Details will be forth coming :))
>>>> The reasons for going with this style architecture are:
>>>> * Obviously there is great confusion as shown in this thread
>>>> * Having FilePath and DirectoryPath makes certain common operations on
>>>> File and Directory a little confusing.  (I have made several code examples
>>>> comparing the two and have seen very little benefit to the FilePath
>>>> architecture)
>>>> Does this sound like a plan?
>>>> Could someone please create a ScalaIO repository in the incubator github
>>>> project for me and add jesseeichar as a collaborator?  I have my code in my
>>>> personal repo but only temporarily until I can put in the incubator.
>>>> Jesse
>>>>
>>>> I managed to go through this thread just now, and in a bit of a hurry I
>>>> admit. But I am aware of thew whole Scala I/O process going on.
>>>> My thoughts have been very clear from the beginning that I saw the new
>>>> Java Path API: They get it wrong once more. The reason the JDK folks get
>>>> this wrong, IMHO, is because they do not separate concerns. It is one thing
>>>> to have a _name_ for an object and a completely different thing to have the
>>>> object (or an idea of what the object stands for).
>>>> A Path has nothing to do with any underlying resource data or metadata,
>>>> besides the fact that is shows the way to obtain them. And of course, it
>>>> inherits any naming non-uniformity/ugliness of the underlying OS (Windows is
>>>> the champion here).
>>>> A Path should be an immutable, type-full representative for a
>>>> (composite) name with some extra algebraic properties (semigroup for sure,
>>>> monoid in principle) with the "/" operator playing the obvious role.
>>>
>>> Also, the object residing at that Path can change willy-nillingly from
>>> underneath.
>>>
>>>>
>>>> If you insist on semantically handling the Path the way it is now,
>>>> please give it another name. What JDK 7 has as Path is not a path at all.
>>>> BR,
>>>> Christos
>>>> --
>>>>    __~O
>>>>   -\ <,       Christos KK Loverdos
>>>> (*)/ (*)      http://ckkloverdos.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>>
>>> Blog: klangism.blogspot.com
>>> Twttr: viktorklang
>>> Wave: viktor.klang@googlewave.com
>>> Code: github.com/viktorklang
>>>
>>> AKKA Committer - akkasource.org
>>> Lift Committer - liftweb.com
>>> Atmosphere Committer - atmosphere.dev.java.net
>>> SoftPub founder: http://groups.google.com/group/softpub
>>
>
>
>
> BR
> Christos.
>
> --
>  __~O
> -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral wrote:
> Guys, stand back. Take a deep breath.
>
> A file/directory API has a main goal, one responsible for 99%+ of its
> expected usage: dealing with files and directories on Windows and Unix. The
> fact that there are many variations on the theme on uncommon operating
> systems is of very, very little relevant. In fact, I'm much more concerned
> about volumes on big iron than with other unusual things talked about here.
>
> The use case is to open and close files, read, write, position and truncate
> them. List files in a directory. Create, delete, rename and move files
> and directories. Identify whether you have permissions for doing it, and
> identify if something can be treated as a file or as a directory. And, in
> all that, use user input to identify them, and display them back to the
> user, in a system-dependent manner (just like locales).
>
> So, whatever you do, make sure THAT is easy. If necessary, make the rest
> complex.

+1.

Quoting Alan Kay: ``Simple things should be simple, complex things
should be possible.''

Cheers

On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral wrote:
> > Guys, stand back. Take a deep breath.
> >
> > A file/directory API has a main goal, one responsible for 99%+ of its
> > expected usage: dealing with files and directories on Windows and Unix.
> > The fact that there are many variations on the theme on
> > uncommon operating systems is of very, very little relevant. In fact, I'm
> > much more concerned about volumes on big iron than with other unusual
> > things talked about here.
> >
> > The use case is to open and close files, read, write, position and
> > truncate them. List files in a directory. Create, delete, rename and move
> > files and directories. Identify whether you have permissions for doing
> > it, and identify if something can be treated as a file or as a directory.
> > And, in all that, use user input to identify them, and display them back
> > to the user, in a system-dependent manner (just like locales).
> >
> > So, whatever you do, make sure THAT is easy. If necessary, make the rest
> > complex.
>
> +1.
>
> Quoting Alan Kay: ``Simple things should be simple, complex things
> should be possible.''
>
> Cheers
>

I'd love to have an underlying representation that mirrors how
filesystems actually behave, taking a domain-driven approach.
Then layer any simplifications we need over the top of that.

Whatever we do, the filesystem is what it is, so we'll always have to
simplify at some point between the FS and user code.
It just feels right to have that intermediate "less simple, but
correct" layer between the two, so we can better handle the
non-trivial use cases.

On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko wrote:
> On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral wrote:
>> > Guys, stand back. Take a deep breath.
>> >
>> > A file/directory API has a main goal, one responsible for 99%+ of its
>> > expected usage: dealing with files and directories on Windows and Unix.
>> > The fact that there are many variations on the theme on
>> > uncommon operating systems is of very, very little relevant. In fact, I'm
>> > much more concerned about volumes on big iron than with other unusual
>> > things talked about here.
>> >
>> > The use case is to open and close files, read, write, position and
>> > truncate them. List files in a directory. Create, delete, rename and move
>> > files and directories. Identify whether you have permissions for doing
>> > it, and identify if something can be treated as a file or as a directory.
>> > And, in all that, use user input to identify them, and display them back
>> > to the user, in a system-dependent manner (just like locales).
>> >
>> > So, whatever you do, make sure THAT is easy. If necessary, make the rest
>> > complex.
>>
>> +1.
>>
>> Quoting Alan Kay: ``Simple things should be simple, complex things
>> should be possible.''
>>
>> Cheers
>>
>>  -- Martin
>
> He-he... :-) A month and half ago I have cried wrt Scala IO (the opinion was
> not shared by somebody):
>
> "Abstractions are for pleasing dealing with concrete things, rather things
> exist to express beautyful abstractions."
>

I agree. But not how using URL to handle Paths, as shown, go... You have a program running somewhere. The program asks for a path to some file from the user, which types that path. Now you need to:   1. Discover whether you are on a Unix, Windows, or whatever; 2. Depending on where you are, call the appropriate conversion to URL. 3. Use that URL to open the file.   That's not even scalable, as you have to hard code every possible variante on path naming.   But the fact is that the user _knows_ what kind of Path the operating system he is _using_ accepts.   Now extend that to parameters passed on the command line, environment variables, configuration files, etc.
On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I'd love to have an underlying representation that mirrors how
filesystems actually behave, taking a domain-driven approach.
Then layer any simplifications we need over the top of that.

Whatever we do, the filesystem is what it is, so we'll always have to
simplify at some point between the FS and user code.
It just feels right to have that intermediate "less simple, but
correct" layer between the two, so we can better handle the
non-trivial use cases.


On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko <a@gaydenko.com> wrote:
> On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > Guys, stand back. Take a deep breath.
>> >
>> > A file/directory API has a main goal, one responsible for 99%+ of its
>> > expected usage: dealing with files and directories on Windows and Unix.
>> > The fact that there are many variations on the theme on
>> > uncommon operating systems is of very, very little relevant. In fact, I'm
>> > much more concerned about volumes on big iron than with other unusual
>> > things talked about here.
>> >
>> > The use case is to open and close files, read, write, position and
>> > truncate them. List files in a directory. Create, delete, rename and move
>> > files and directories. Identify whether you have permissions for doing
>> > it, and identify if something can be treated as a file or as a directory.
>> > And, in all that, use user input to identify them, and display them back
>> > to the user, in a system-dependent manner (just like locales).
>> >
>> > So, whatever you do, make sure THAT is easy. If necessary, make the rest
>> > complex.
>>
>> +1.
>>
>> Quoting Alan Kay: ``Simple things should be simple, complex things
>> should be possible.''
>>
>> Cheers
>>
>>  -- Martin
>
> He-he... :-) A month and half ago I have cried wrt Scala IO (the opinion was
> not shared by somebody):
>
> "Abstractions are for pleasing dealing with concrete things, rather things
> exist to express beautyful abstractions."
>

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

I think we can be smarter than that

starting with file:// or another protocol prefix = pure URL
starting with c:, d:, e:, ... = windows
starting \\ = windows
using only \ = windows
starting / = unix
using only / = windows

The tricky part is relative paths, where people will frequently use /
regardless of the OS
It's also makes no sense to have an OS-specific relative path

So... perhaps there should be a type separation between absolute and
relative path forms. I can see several benefits to that approach.

Maybe something like this would work as a type hierarchy:

Path
- RelativePath
- AbsolutePath
- - UrlPath
- - WindowsPath
- - UnixPath

On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral wrote:
> I agree. But not how using URL to handle Paths, as shown, go... You have a
> program running somewhere. The program asks for a path to some file from the
> user, which types that path. Now you need to:
>
> 1. Discover whether you are on a Unix, Windows, or whatever;
> 2. Depending on where you are, call the appropriate conversion to URL.
> 3. Use that URL to open the file.
>
> That's not even scalable, as you have to hard code every possible variante
> on path naming.
>
> But the fact is that the user _knows_ what kind of Path the operating system
> he is _using_ accepts.
>
> Now extend that to parameters passed on the command line, environment
> variables, configuration files, etc.
> On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
> wrote:
>>
>> I'd love to have an underlying representation that mirrors how
>> filesystems actually behave, taking a domain-driven approach.
>> Then layer any simplifications we need over the top of that.
>>
>> Whatever we do, the filesystem is what it is, so we'll always have to
>> simplify at some point between the FS and user code.
>> It just feels right to have that intermediate "less simple, but
>> correct" layer between the two, so we can better handle the
>> non-trivial use cases.
>>
>>
>> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko wrote:
>> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>> >> wrote:
>> >> > Guys, stand back. Take a deep breath.
>> >> >
>> >> > A file/directory API has a main goal, one responsible for 99%+ of its
>> >> > expected usage: dealing with files and directories on Windows and
>> >> > Unix.
>> >> > The fact that there are many variations on the theme on
>> >> > uncommon operating systems is of very, very little relevant. In fact,
>> >> > I'm
>> >> > much more concerned about volumes on big iron than with other unusual
>> >> > things talked about here.
>> >> >
>> >> > The use case is to open and close files, read, write, position and
>> >> > truncate them. List files in a directory. Create, delete, rename and
>> >> > move
>> >> > files and directories. Identify whether you have permissions for
>> >> > doing
>> >> > it, and identify if something can be treated as a file or as a
>> >> > directory.
>> >> > And, in all that, use user input to identify them, and display them
>> >> > back
>> >> > to the user, in a system-dependent manner (just like locales).
>> >> >
>> >> > So, whatever you do, make sure THAT is easy. If necessary, make the
>> >> > rest
>> >> > complex.
>> >>
>> >> +1.
>> >>
>> >> Quoting Alan Kay: ``Simple things should be simple, complex things
>> >> should be possible.''
>> >>
>> >> Cheers
>> >>
>> >>  -- Martin
>> >
>> > He-he... :-) A month and half ago I have cried wrt Scala IO (the opinion
>> > was
>> > not shared by somebody):
>> >
>> > "Abstractions are for pleasing dealing with concrete things, rather
>> > things
>> > exist to express beautyful abstractions."
>> >
>
>
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>

On Wed, Oct 21, 2009 at 1:51 PM, Kevin Wright
wrote:
> I think we can be smarter than that
>
> starting with file:// or another protocol prefix = pure URL
> starting with c:, d:, e:, ... = windows
> starting \\ = windows
> using only \ = windows
> starting / = unix
> using only / = windows

correction:
using only / = unix

> The tricky part is relative paths, where people will frequently use /
> regardless of the OS
> It's also makes no sense to have an OS-specific relative path
>
> So... perhaps there should be a type separation between absolute and
> relative path forms.  I can see several benefits to that approach.
>
>
> Maybe something like this would work as a type hierarchy:
>
> Path
> - RelativePath
> - AbsolutePath
> - - UrlPath
> - - WindowsPath
> - - UnixPath
>
>
> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral wrote:
>> I agree. But not how using URL to handle Paths, as shown, go... You have a
>> program running somewhere. The program asks for a path to some file from the
>> user, which types that path. Now you need to:
>>
>> 1. Discover whether you are on a Unix, Windows, or whatever;
>> 2. Depending on where you are, call the appropriate conversion to URL.
>> 3. Use that URL to open the file.
>>
>> That's not even scalable, as you have to hard code every possible variante
>> on path naming.
>>
>> But the fact is that the user _knows_ what kind of Path the operating system
>> he is _using_ accepts.
>>
>> Now extend that to parameters passed on the command line, environment
>> variables, configuration files, etc.
>> On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>> wrote:
>>>
>>> I'd love to have an underlying representation that mirrors how
>>> filesystems actually behave, taking a domain-driven approach.
>>> Then layer any simplifications we need over the top of that.
>>>
>>> Whatever we do, the filesystem is what it is, so we'll always have to
>>> simplify at some point between the FS and user code.
>>> It just feels right to have that intermediate "less simple, but
>>> correct" layer between the two, so we can better handle the
>>> non-trivial use cases.
>>>
>>>
>>> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko wrote:
>>> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>>> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>>> >> wrote:
>>> >> > Guys, stand back. Take a deep breath.
>>> >> >
>>> >> > A file/directory API has a main goal, one responsible for 99%+ of its
>>> >> > expected usage: dealing with files and directories on Windows and
>>> >> > Unix.
>>> >> > The fact that there are many variations on the theme on
>>> >> > uncommon operating systems is of very, very little relevant. In fact,
>>> >> > I'm
>>> >> > much more concerned about volumes on big iron than with other unusual
>>> >> > things talked about here.
>>> >> >
>>> >> > The use case is to open and close files, read, write, position and
>>> >> > truncate them. List files in a directory. Create, delete, rename and
>>> >> > move
>>> >> > files and directories. Identify whether you have permissions for
>>> >> > doing
>>> >> > it, and identify if something can be treated as a file or as a
>>> >> > directory.
>>> >> > And, in all that, use user input to identify them, and display them
>>> >> > back
>>> >> > to the user, in a system-dependent manner (just like locales).
>>> >> >
>>> >> > So, whatever you do, make sure THAT is easy. If necessary, make the
>>> >> > rest
>>> >> > complex.
>>> >>
>>> >> +1.
>>> >>
>>> >> Quoting Alan Kay: ``Simple things should be simple, complex things
>>> >> should be possible.''
>>> >>
>>> >> Cheers
>>> >>
>>> >>  -- Martin
>>> >
>>> > He-he... :-) A month and half ago I have cried wrt Scala IO (the opinion
>>> > was
>>> > not shared by somebody):
>>> >
>>> > "Abstractions are for pleasing dealing with concrete things, rather
>>> > things
>>> > exist to express beautyful abstractions."
>>> >
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> Something I learned in academia: there are three kinds of academic reviews:
>> review by name, review by reference and review by value.
>>
>

On Windows, people almost always use the relative path of the form "..\..\" for local files, not "../../" (which only works with file://).
I would separate concern between manipulating paths (as URI) and converting them to specific representations. Something like Path composes an IPathConverter which allows to convert from/to OS specific representations. It could also be done in a more functional way with converter function instead of interface.
Sébastien
On Wed, Oct 21, 2009 at 08:51, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

I think we can be smarter than that

starting with file:// or another protocol prefix = pure URL
starting with c:, d:, e:, ... = windows
starting \\ = windows
using only \ = windows
starting / = unix
using only / = windows

The tricky part is relative paths, where people will frequently use /
regardless of the OS
It's also makes no sense to have an OS-specific relative path

So... perhaps there should be a type separation between absolute and
relative path forms.  I can see several benefits to that approach.


Maybe something like this would work as a type hierarchy:

Path
- RelativePath
- AbsolutePath
- - UrlPath
- - WindowsPath
- - UnixPath


On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
> I agree. But not how using URL to handle Paths, as shown, go... You have a
> program running somewhere. The program asks for a path to some file from the
> user, which types that path. Now you need to:
>
> 1. Discover whether you are on a Unix, Windows, or whatever;
> 2. Depending on where you are, call the appropriate conversion to URL.
> 3. Use that URL to open the file.
>
> That's not even scalable, as you have to hard code every possible variante
> on path naming.
>
> But the fact is that the user _knows_ what kind of Path the operating system
> he is _using_ accepts.
>
> Now extend that to parameters passed on the command line, environment
> variables, configuration files, etc.
> On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
> <kev.lee.wright@googlemail.com> wrote:
>>
>> I'd love to have an underlying representation that mirrors how
>> filesystems actually behave, taking a domain-driven approach.
>> Then layer any simplifications we need over the top of that.
>>
>> Whatever we do, the filesystem is what it is, so we'll always have to
>> simplify at some point between the FS and user code.
>> It just feels right to have that intermediate "less simple, but
>> correct" layer between the two, so we can better handle the
>> non-trivial use cases.
>>
>>
>> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko <a@gaydenko.com> wrote:
>> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral <dcsobral@gmail.com>
>> >> wrote:
>> >> > Guys, stand back. Take a deep breath.
>> >> >
>> >> > A file/directory API has a main goal, one responsible for 99%+ of its
>> >> > expected usage: dealing with files and directories on Windows and
>> >> > Unix.
>> >> > The fact that there are many variations on the theme on
>> >> > uncommon operating systems is of very, very little relevant. In fact,
>> >> > I'm
>> >> > much more concerned about volumes on big iron than with other unusual
>> >> > things talked about here.
>> >> >
>> >> > The use case is to open and close files, read, write, position and
>> >> > truncate them. List files in a directory. Create, delete, rename and
>> >> > move
>> >> > files and directories. Identify whether you have permissions for
>> >> > doing
>> >> > it, and identify if something can be treated as a file or as a
>> >> > directory.
>> >> > And, in all that, use user input to identify them, and display them
>> >> > back
>> >> > to the user, in a system-dependent manner (just like locales).
>> >> >
>> >> > So, whatever you do, make sure THAT is easy. If necessary, make the
>> >> > rest
>> >> > complex.
>> >>
>> >> +1.
>> >>
>> >> Quoting Alan Kay: ``Simple things should be simple, complex things
>> >> should be possible.''
>> >>
>> >> Cheers
>> >>
>> >>  -- Martin
>> >
>> > He-he... :-) A month and half ago I have cried wrt Scala IO (the opinion
>> > was
>> > not shared by somebody):
>> >
>> > "Abstractions are for pleasing dealing with concrete things, rather
>> > things
>> > exist to express beautyful abstractions."
>> >
>
>
>
> --
> Daniel C. Sobral
>
> Something I learned in academia: there are three kinds of academic reviews:
> review by name, review by reference and review by value.
>

On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
wrote:
> On Windows, people almost always use the relative path of the form "..\..\"
> for local files, not "../../" (which only works with file://).

This doesn't match my experience, almost every config file I write for
java apps uses / as a separator, regardless of operating system.
(most of these apps run on both windows and linux anyway)

Anything typed in by end users should use \ though, and anything via
by a gui almost certainly will.

It's also possible that some relative paths could be pre-defined and
then resolved at runtime (i.e. by making relative to the app
directory), this means that the same relative path could be used on
different OSs - which is why I think relative and absolute paths
should be treated as different beasts.

> I would separate concern between manipulating paths (as URI) and converting
> them to specific representations. Something like Path composes an
> IPathConverter which allows to convert from/to OS specific representations.
> It could also be done in a more functional way with converter function
> instead of interface.
> Sébastien
> On Wed, Oct 21, 2009 at 08:51, Kevin Wright
> wrote:
>>
>> I think we can be smarter than that
>>
>> starting with file:// or another protocol prefix = pure URL
>> starting with c:, d:, e:, ... = windows
>> starting \\ = windows
>> using only \ = windows
>> starting / = unix
>> using only / = windows
>>
>> The tricky part is relative paths, where people will frequently use /
>> regardless of the OS
>> It's also makes no sense to have an OS-specific relative path
>>
>> So... perhaps there should be a type separation between absolute and
>> relative path forms.  I can see several benefits to that approach.
>>
>>
>> Maybe something like this would work as a type hierarchy:
>>
>> Path
>> - RelativePath
>> - AbsolutePath
>> - - UrlPath
>> - - WindowsPath
>> - - UnixPath
>>
>>
>> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral wrote:
>> > I agree. But not how using URL to handle Paths, as shown, go... You have
>> > a
>> > program running somewhere. The program asks for a path to some file from
>> > the
>> > user, which types that path. Now you need to:
>> >
>> > 1. Discover whether you are on a Unix, Windows, or whatever;
>> > 2. Depending on where you are, call the appropriate conversion to URL.
>> > 3. Use that URL to open the file.
>> >
>> > That's not even scalable, as you have to hard code every possible
>> > variante
>> > on path naming.
>> >
>> > But the fact is that the user _knows_ what kind of Path the operating
>> > system
>> > he is _using_ accepts.
>> >
>> > Now extend that to parameters passed on the command line, environment
>> > variables, configuration files, etc.
>> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>> > wrote:
>> >>
>> >> I'd love to have an underlying representation that mirrors how
>> >> filesystems actually behave, taking a domain-driven approach.
>> >> Then layer any simplifications we need over the top of that.
>> >>
>> >> Whatever we do, the filesystem is what it is, so we'll always have to
>> >> simplify at some point between the FS and user code.
>> >> It just feels right to have that intermediate "less simple, but
>> >> correct" layer between the two, so we can better handle the
>> >> non-trivial use cases.
>> >>
>> >>
>> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko
>> >> wrote:
>> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>> >> >> wrote:
>> >> >> > Guys, stand back. Take a deep breath.
>> >> >> >
>> >> >> > A file/directory API has a main goal, one responsible for 99%+ of
>> >> >> > its
>> >> >> > expected usage: dealing with files and directories on Windows and
>> >> >> > Unix.
>> >> >> > The fact that there are many variations on the theme on
>> >> >> > uncommon operating systems is of very, very little relevant. In
>> >> >> > fact,
>> >> >> > I'm
>> >> >> > much more concerned about volumes on big iron than with other
>> >> >> > unusual
>> >> >> > things talked about here.
>> >> >> >
>> >> >> > The use case is to open and close files, read, write, position and
>> >> >> > truncate them. List files in a directory. Create, delete, rename
>> >> >> > and
>> >> >> > move
>> >> >> > files and directories. Identify whether you have permissions for
>> >> >> > doing
>> >> >> > it, and identify if something can be treated as a file or as a
>> >> >> > directory.
>> >> >> > And, in all that, use user input to identify them, and display
>> >> >> > them
>> >> >> > back
>> >> >> > to the user, in a system-dependent manner (just like locales).
>> >> >> >
>> >> >> > So, whatever you do, make sure THAT is easy. If necessary, make
>> >> >> > the
>> >> >> > rest
>> >> >> > complex.
>> >> >>
>> >> >> +1.
>> >> >>
>> >> >> Quoting Alan Kay: ``Simple things should be simple, complex things
>> >> >> should be possible.''
>> >> >>
>> >> >> Cheers
>> >> >>
>> >> >>  -- Martin
>> >> >
>> >> > He-he... :-) A month and half ago I have cried wrt Scala IO (the
>> >> > opinion
>> >> > was
>> >> > not shared by somebody):
>> >> >
>> >> > "Abstractions are for pleasing dealing with concrete things, rather
>> >> > things
>> >> > exist to express beautyful abstractions."
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > Something I learned in academia: there are three kinds of academic
>> > reviews:
>> > review by name, review by reference and review by value.
>> >
>
>

Java is abstracting them, on Windows, it's really "..\..\". In .NET, it is using a readonly field named System.IO.Path.DirectorySeparatorChar, which changes according to the platform. On Windows, it is "\".

Sébastien
On Thu, Oct 22, 2009 at 04:55, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
<sl@thestrangefactory.com> wrote:
> On Windows, people almost always use the relative path of the form "..\..\"
> for local files, not "../../" (which only works with file://).

This doesn't match my experience, almost every config file I write for
java apps uses / as a separator, regardless of operating system.
(most of these apps run on both windows and linux anyway)

Anything typed in by end users should use \ though, and anything via
by a gui almost certainly will.

It's also possible that some relative paths could be pre-defined and
then resolved at runtime (i.e. by making relative to the app
directory), this means that the same relative path could be used on
different OSs - which is why I think relative and absolute paths
should be treated as different beasts.

> I would separate concern between manipulating paths (as URI) and converting
> them to specific representations. Something like Path composes an
> IPathConverter which allows to convert from/to OS specific representations.
> It could also be done in a more functional way with converter function
> instead of interface.
> Sébastien
> On Wed, Oct 21, 2009 at 08:51, Kevin Wright <kev.lee.wright@googlemail.com>
> wrote:
>>
>> I think we can be smarter than that
>>
>> starting with file:// or another protocol prefix = pure URL
>> starting with c:, d:, e:, ... = windows
>> starting \\ = windows
>> using only \ = windows
>> starting / = unix
>> using only / = windows
>>
>> The tricky part is relative paths, where people will frequently use /
>> regardless of the OS
>> It's also makes no sense to have an OS-specific relative path
>>
>> So... perhaps there should be a type separation between absolute and
>> relative path forms.  I can see several benefits to that approach.
>>
>>
>> Maybe something like this would work as a type hierarchy:
>>
>> Path
>> - RelativePath
>> - AbsolutePath
>> - - UrlPath
>> - - WindowsPath
>> - - UnixPath
>>
>>
>> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
>> > I agree. But not how using URL to handle Paths, as shown, go... You have
>> > a
>> > program running somewhere. The program asks for a path to some file from
>> > the
>> > user, which types that path. Now you need to:
>> >
>> > 1. Discover whether you are on a Unix, Windows, or whatever;
>> > 2. Depending on where you are, call the appropriate conversion to URL.
>> > 3. Use that URL to open the file.
>> >
>> > That's not even scalable, as you have to hard code every possible
>> > variante
>> > on path naming.
>> >
>> > But the fact is that the user _knows_ what kind of Path the operating
>> > system
>> > he is _using_ accepts.
>> >
>> > Now extend that to parameters passed on the command line, environment
>> > variables, configuration files, etc.
>> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>> > <kev.lee.wright@googlemail.com> wrote:
>> >>
>> >> I'd love to have an underlying representation that mirrors how
>> >> filesystems actually behave, taking a domain-driven approach.
>> >> Then layer any simplifications we need over the top of that.
>> >>
>> >> Whatever we do, the filesystem is what it is, so we'll always have to
>> >> simplify at some point between the FS and user code.
>> >> It just feels right to have that intermediate "less simple, but
>> >> correct" layer between the two, so we can better handle the
>> >> non-trivial use cases.
>> >>
>> >>
>> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko <a@gaydenko.com>
>> >> wrote:
>> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral <dcsobral@gmail.com>
>> >> >> wrote:
>> >> >> > Guys, stand back. Take a deep breath.
>> >> >> >
>> >> >> > A file/directory API has a main goal, one responsible for 99%+ of
>> >> >> > its
>> >> >> > expected usage: dealing with files and directories on Windows and
>> >> >> > Unix.
>> >> >> > The fact that there are many variations on the theme on
>> >> >> > uncommon operating systems is of very, very little relevant. In
>> >> >> > fact,
>> >> >> > I'm
>> >> >> > much more concerned about volumes on big iron than with other
>> >> >> > unusual
>> >> >> > things talked about here.
>> >> >> >
>> >> >> > The use case is to open and close files, read, write, position and
>> >> >> > truncate them. List files in a directory. Create, delete, rename
>> >> >> > and
>> >> >> > move
>> >> >> > files and directories. Identify whether you have permissions for
>> >> >> > doing
>> >> >> > it, and identify if something can be treated as a file or as a
>> >> >> > directory.
>> >> >> > And, in all that, use user input to identify them, and display
>> >> >> > them
>> >> >> > back
>> >> >> > to the user, in a system-dependent manner (just like locales).
>> >> >> >
>> >> >> > So, whatever you do, make sure THAT is easy. If necessary, make
>> >> >> > the
>> >> >> > rest
>> >> >> > complex.
>> >> >>
>> >> >> +1.
>> >> >>
>> >> >> Quoting Alan Kay: ``Simple things should be simple, complex things
>> >> >> should be possible.''
>> >> >>
>> >> >> Cheers
>> >> >>
>> >> >>  -- Martin
>> >> >
>> >> > He-he... :-) A month and half ago I have cried wrt Scala IO (the
>> >> > opinion
>> >> > was
>> >> > not shared by somebody):
>> >> >
>> >> > "Abstractions are for pleasing dealing with concrete things, rather
>> >> > things
>> >> > exist to express beautyful abstractions."
>> >> >
>> >
>> >
>> >
>> > --
>> > Daniel C. Sobral
>> >
>> > Something I learned in academia: there are three kinds of academic
>> > reviews:
>> > review by name, review by reference and review by value.
>> >
>
>

On Thu, Oct 22, 2009 at 2:01 PM, Sébastien Lorion
wrote:
> Java is abstracting them, on Windows, it's really "..\..\". In .NET, it is
> using a readonly field named System.IO.Path.DirectorySeparatorChar, which
> changes according to the platform. On Windows, it is "\".

Windows will also accept / used on the command line (think that one
first came in with windows NT, when MS were keen on getting people to
migrate from unix)

So this isn't just a Java abstraction, although I have no doubt lots
of code exists that normalises paths to the usual windows convention

> Sébastien
> On Thu, Oct 22, 2009 at 04:55, Kevin Wright
> wrote:
>>
>> On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
>> wrote:
>> > On Windows, people almost always use the relative path of the form
>> > "..\..\"
>> > for local files, not "../../" (which only works with file://).
>>
>> This doesn't match my experience, almost every config file I write for
>> java apps uses / as a separator, regardless of operating system.
>> (most of these apps run on both windows and linux anyway)
>>
>> Anything typed in by end users should use \ though, and anything via
>> by a gui almost certainly will.
>>
>> It's also possible that some relative paths could be pre-defined and
>> then resolved at runtime (i.e. by making relative to the app
>> directory), this means that the same relative path could be used on
>> different OSs - which is why I think relative and absolute paths
>> should be treated as different beasts.
>>
>> > I would separate concern between manipulating paths (as URI) and
>> > converting
>> > them to specific representations. Something like Path composes an
>> > IPathConverter which allows to convert from/to OS specific
>> > representations.
>> > It could also be done in a more functional way with converter function
>> > instead of interface.
>> > Sébastien
>> > On Wed, Oct 21, 2009 at 08:51, Kevin Wright
>> >
>> > wrote:
>> >>
>> >> I think we can be smarter than that
>> >>
>> >> starting with file:// or another protocol prefix = pure URL
>> >> starting with c:, d:, e:, ... = windows
>> >> starting \\ = windows
>> >> using only \ = windows
>> >> starting / = unix
>> >> using only / = windows
>> >>
>> >> The tricky part is relative paths, where people will frequently use /
>> >> regardless of the OS
>> >> It's also makes no sense to have an OS-specific relative path
>> >>
>> >> So... perhaps there should be a type separation between absolute and
>> >> relative path forms.  I can see several benefits to that approach.
>> >>
>> >>
>> >> Maybe something like this would work as a type hierarchy:
>> >>
>> >> Path
>> >> - RelativePath
>> >> - AbsolutePath
>> >> - - UrlPath
>> >> - - WindowsPath
>> >> - - UnixPath
>> >>
>> >>
>> >> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral
>> >> wrote:
>> >> > I agree. But not how using URL to handle Paths, as shown, go... You
>> >> > have
>> >> > a
>> >> > program running somewhere. The program asks for a path to some file
>> >> > from
>> >> > the
>> >> > user, which types that path. Now you need to:
>> >> >
>> >> > 1. Discover whether you are on a Unix, Windows, or whatever;
>> >> > 2. Depending on where you are, call the appropriate conversion to
>> >> > URL.
>> >> > 3. Use that URL to open the file.
>> >> >
>> >> > That's not even scalable, as you have to hard code every possible
>> >> > variante
>> >> > on path naming.
>> >> >
>> >> > But the fact is that the user _knows_ what kind of Path the operating
>> >> > system
>> >> > he is _using_ accepts.
>> >> >
>> >> > Now extend that to parameters passed on the command line, environment
>> >> > variables, configuration files, etc.
>> >> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>> >> > wrote:
>> >> >>
>> >> >> I'd love to have an underlying representation that mirrors how
>> >> >> filesystems actually behave, taking a domain-driven approach.
>> >> >> Then layer any simplifications we need over the top of that.
>> >> >>
>> >> >> Whatever we do, the filesystem is what it is, so we'll always have
>> >> >> to
>> >> >> simplify at some point between the FS and user code.
>> >> >> It just feels right to have that intermediate "less simple, but
>> >> >> correct" layer between the two, so we can better handle the
>> >> >> non-trivial use cases.
>> >> >>
>> >> >>
>> >> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko
>> >> >> wrote:
>> >> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >> > Guys, stand back. Take a deep breath.
>> >> >> >> >
>> >> >> >> > A file/directory API has a main goal, one responsible for 99%+
>> >> >> >> > of
>> >> >> >> > its
>> >> >> >> > expected usage: dealing with files and directories on Windows
>> >> >> >> > and
>> >> >> >> > Unix.
>> >> >> >> > The fact that there are many variations on the theme on
>> >> >> >> > uncommon operating systems is of very, very little relevant. In
>> >> >> >> > fact,
>> >> >> >> > I'm
>> >> >> >> > much more concerned about volumes on big iron than with other
>> >> >> >> > unusual
>> >> >> >> > things talked about here.
>> >> >> >> >
>> >> >> >> > The use case is to open and close files, read, write, position
>> >> >> >> > and
>> >> >> >> > truncate them. List files in a directory. Create, delete,
>> >> >> >> > rename
>> >> >> >> > and
>> >> >> >> > move
>> >> >> >> > files and directories. Identify whether you have permissions
>> >> >> >> > for
>> >> >> >> > doing
>> >> >> >> > it, and identify if something can be treated as a file or as a
>> >> >> >> > directory.
>> >> >> >> > And, in all that, use user input to identify them, and display
>> >> >> >> > them
>> >> >> >> > back
>> >> >> >> > to the user, in a system-dependent manner (just like locales).
>> >> >> >> >
>> >> >> >> > So, whatever you do, make sure THAT is easy. If necessary, make
>> >> >> >> > the
>> >> >> >> > rest
>> >> >> >> > complex.
>> >> >> >>
>> >> >> >> +1.
>> >> >> >>
>> >> >> >> Quoting Alan Kay: ``Simple things should be simple, complex
>> >> >> >> things
>> >> >> >> should be possible.''
>> >> >> >>
>> >> >> >> Cheers
>> >> >> >>
>> >> >> >>  -- Martin
>> >> >> >
>> >> >> > He-he... :-) A month and half ago I have cried wrt Scala IO (the
>> >> >> > opinion
>> >> >> > was
>> >> >> > not shared by somebody):
>> >> >> >
>> >> >> > "Abstractions are for pleasing dealing with concrete things,
>> >> >> > rather
>> >> >> > things
>> >> >> > exist to express beautyful abstractions."
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Daniel C. Sobral
>> >> >
>> >> > Something I learned in academia: there are three kinds of academic
>> >> > reviews:
>> >> > review by name, review by reference and review by value.
>> >> >
>> >
>> >
>
>

Windows will, yes, but there are cases where it won't. Really basic
cases, e.g., dir /

2009/10/22 Kevin Wright :
> On Thu, Oct 22, 2009 at 2:01 PM, Sébastien Lorion
> wrote:
>> Java is abstracting them, on Windows, it's really "..\..\". In .NET, it is
>> using a readonly field named System.IO.Path.DirectorySeparatorChar, which
>> changes according to the platform. On Windows, it is "\".
>
> Windows will also accept / used on the command line (think that one
> first came in with windows NT, when MS were keen on getting people to
> migrate from unix)
>
> So this isn't just a Java abstraction, although I have no doubt lots
> of code exists that normalises paths to the usual windows convention
>
>
>> Sébastien
>> On Thu, Oct 22, 2009 at 04:55, Kevin Wright
>> wrote:
>>>
>>> On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
>>> wrote:
>>> > On Windows, people almost always use the relative path of the form
>>> > "..\..\"
>>> > for local files, not "../../" (which only works with file://).
>>>
>>> This doesn't match my experience, almost every config file I write for
>>> java apps uses / as a separator, regardless of operating system.
>>> (most of these apps run on both windows and linux anyway)
>>>
>>> Anything typed in by end users should use \ though, and anything via
>>> by a gui almost certainly will.
>>>
>>> It's also possible that some relative paths could be pre-defined and
>>> then resolved at runtime (i.e. by making relative to the app
>>> directory), this means that the same relative path could be used on
>>> different OSs - which is why I think relative and absolute paths
>>> should be treated as different beasts.
>>>
>>> > I would separate concern between manipulating paths (as URI) and
>>> > converting
>>> > them to specific representations. Something like Path composes an
>>> > IPathConverter which allows to convert from/to OS specific
>>> > representations.
>>> > It could also be done in a more functional way with converter function
>>> > instead of interface.
>>> > Sébastien
>>> > On Wed, Oct 21, 2009 at 08:51, Kevin Wright
>>> >
>>> > wrote:
>>> >>
>>> >> I think we can be smarter than that
>>> >>
>>> >> starting with file:// or another protocol prefix = pure URL
>>> >> starting with c:, d:, e:, ... = windows
>>> >> starting \\ = windows
>>> >> using only \ = windows
>>> >> starting / = unix
>>> >> using only / = windows
>>> >>
>>> >> The tricky part is relative paths, where people will frequently use /
>>> >> regardless of the OS
>>> >> It's also makes no sense to have an OS-specific relative path
>>> >>
>>> >> So... perhaps there should be a type separation between absolute and
>>> >> relative path forms.  I can see several benefits to that approach.
>>> >>
>>> >>
>>> >> Maybe something like this would work as a type hierarchy:
>>> >>
>>> >> Path
>>> >> - RelativePath
>>> >> - AbsolutePath
>>> >> - - UrlPath
>>> >> - - WindowsPath
>>> >> - - UnixPath
>>> >>
>>> >>
>>> >> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral
>>> >> wrote:
>>> >> > I agree. But not how using URL to handle Paths, as shown, go... You
>>> >> > have
>>> >> > a
>>> >> > program running somewhere. The program asks for a path to some file
>>> >> > from
>>> >> > the
>>> >> > user, which types that path. Now you need to:
>>> >> >
>>> >> > 1. Discover whether you are on a Unix, Windows, or whatever;
>>> >> > 2. Depending on where you are, call the appropriate conversion to
>>> >> > URL.
>>> >> > 3. Use that URL to open the file.
>>> >> >
>>> >> > That's not even scalable, as you have to hard code every possible
>>> >> > variante
>>> >> > on path naming.
>>> >> >
>>> >> > But the fact is that the user _knows_ what kind of Path the operating
>>> >> > system
>>> >> > he is _using_ accepts.
>>> >> >
>>> >> > Now extend that to parameters passed on the command line, environment
>>> >> > variables, configuration files, etc.
>>> >> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>>> >> > wrote:
>>> >> >>
>>> >> >> I'd love to have an underlying representation that mirrors how
>>> >> >> filesystems actually behave, taking a domain-driven approach.
>>> >> >> Then layer any simplifications we need over the top of that.
>>> >> >>
>>> >> >> Whatever we do, the filesystem is what it is, so we'll always have
>>> >> >> to
>>> >> >> simplify at some point between the FS and user code.
>>> >> >> It just feels right to have that intermediate "less simple, but
>>> >> >> correct" layer between the two, so we can better handle the
>>> >> >> non-trivial use cases.
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko
>>> >> >> wrote:
>>> >> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>>> >> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>>> >> >> >>
>>> >> >> >> wrote:
>>> >> >> >> > Guys, stand back. Take a deep breath.
>>> >> >> >> >
>>> >> >> >> > A file/directory API has a main goal, one responsible for 99%+
>>> >> >> >> > of
>>> >> >> >> > its
>>> >> >> >> > expected usage: dealing with files and directories on Windows
>>> >> >> >> > and
>>> >> >> >> > Unix.
>>> >> >> >> > The fact that there are many variations on the theme on
>>> >> >> >> > uncommon operating systems is of very, very little relevant. In
>>> >> >> >> > fact,
>>> >> >> >> > I'm
>>> >> >> >> > much more concerned about volumes on big iron than with other
>>> >> >> >> > unusual
>>> >> >> >> > things talked about here.
>>> >> >> >> >
>>> >> >> >> > The use case is to open and close files, read, write, position
>>> >> >> >> > and
>>> >> >> >> > truncate them. List files in a directory. Create, delete,
>>> >> >> >> > rename
>>> >> >> >> > and
>>> >> >> >> > move
>>> >> >> >> > files and directories. Identify whether you have permissions
>>> >> >> >> > for
>>> >> >> >> > doing
>>> >> >> >> > it, and identify if something can be treated as a file or as a
>>> >> >> >> > directory.
>>> >> >> >> > And, in all that, use user input to identify them, and display
>>> >> >> >> > them
>>> >> >> >> > back
>>> >> >> >> > to the user, in a system-dependent manner (just like locales).
>>> >> >> >> >
>>> >> >> >> > So, whatever you do, make sure THAT is easy. If necessary, make
>>> >> >> >> > the
>>> >> >> >> > rest
>>> >> >> >> > complex.
>>> >> >> >>
>>> >> >> >> +1.
>>> >> >> >>
>>> >> >> >> Quoting Alan Kay: ``Simple things should be simple, complex
>>> >> >> >> things
>>> >> >> >> should be possible.''
>>> >> >> >>
>>> >> >> >> Cheers
>>> >> >> >>
>>> >> >> >>  -- Martin
>>> >> >> >
>>> >> >> > He-he... :-) A month and half ago I have cried wrt Scala IO (the
>>> >> >> > opinion
>>> >> >> > was
>>> >> >> > not shared by somebody):
>>> >> >> >
>>> >> >> > "Abstractions are for pleasing dealing with concrete things,
>>> >> >> > rather
>>> >> >> > things
>>> >> >> > exist to express beautyful abstractions."
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Daniel C. Sobral
>>> >> >
>>> >> > Something I learned in academia: there are three kinds of academic
>>> >> > reviews:
>>> >> > review by name, review by reference and review by value.
>>> >> >
>>> >
>>> >
>>
>>
>

Yes, the Windows API supports it (mainly because of Unix Services), but it is very seldom used in typical Windows code and a lot of applications/libraries will break if they receive an unix-style relative path.

Sébastien

On Thu, Oct 22, 2009 at 09:41, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

Windows will, yes, but there are cases where it won't.  Really basic
cases, e.g., dir /

2009/10/22 Kevin Wright <kev.lee.wright@googlemail.com>:
> On Thu, Oct 22, 2009 at 2:01 PM, Sébastien Lorion
> <sl@thestrangefactory.com> wrote:
>> Java is abstracting them, on Windows, it's really "..\..\". In .NET, it is
>> using a readonly field named System.IO.Path.DirectorySeparatorChar, which
>> changes according to the platform. On Windows, it is "\".
>
> Windows will also accept / used on the command line (think that one
> first came in with windows NT, when MS were keen on getting people to
> migrate from unix)
>
> So this isn't just a Java abstraction, although I have no doubt lots
> of code exists that normalises paths to the usual windows convention
>
>
>> Sébastien
>> On Thu, Oct 22, 2009 at 04:55, Kevin Wright <kev.lee.wright@googlemail.com>
>> wrote:
>>>
>>> On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
>>> <sl@thestrangefactory.com> wrote:
>>> > On Windows, people almost always use the relative path of the form
>>> > "..\..\"
>>> > for local files, not "../../" (which only works with file://).
>>>
>>> This doesn't match my experience, almost every config file I write for
>>> java apps uses / as a separator, regardless of operating system.
>>> (most of these apps run on both windows and linux anyway)
>>>
>>> Anything typed in by end users should use \ though, and anything via
>>> by a gui almost certainly will.
>>>
>>> It's also possible that some relative paths could be pre-defined and
>>> then resolved at runtime (i.e. by making relative to the app
>>> directory), this means that the same relative path could be used on
>>> different OSs - which is why I think relative and absolute paths
>>> should be treated as different beasts.
>>>
>>> > I would separate concern between manipulating paths (as URI) and
>>> > converting
>>> > them to specific representations. Something like Path composes an
>>> > IPathConverter which allows to convert from/to OS specific
>>> > representations.
>>> > It could also be done in a more functional way with converter function
>>> > instead of interface.
>>> > Sébastien
>>> > On Wed, Oct 21, 2009 at 08:51, Kevin Wright
>>> > <kev.lee.wright@googlemail.com>
>>> > wrote:
>>> >>
>>> >> I think we can be smarter than that
>>> >>
>>> >> starting with file:// or another protocol prefix = pure URL
>>> >> starting with c:, d:, e:, ... = windows
>>> >> starting \\ = windows
>>> >> using only \ = windows
>>> >> starting / = unix
>>> >> using only / = windows
>>> >>
>>> >> The tricky part is relative paths, where people will frequently use /
>>> >> regardless of the OS
>>> >> It's also makes no sense to have an OS-specific relative path
>>> >>
>>> >> So... perhaps there should be a type separation between absolute and
>>> >> relative path forms.  I can see several benefits to that approach.
>>> >>
>>> >>
>>> >> Maybe something like this would work as a type hierarchy:
>>> >>
>>> >> Path
>>> >> - RelativePath
>>> >> - AbsolutePath
>>> >> - - UrlPath
>>> >> - - WindowsPath
>>> >> - - UnixPath
>>> >>
>>> >>
>>> >> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral <dcsobral@gmail.com>
>>> >> wrote:
>>> >> > I agree. But not how using URL to handle Paths, as shown, go... You
>>> >> > have
>>> >> > a
>>> >> > program running somewhere. The program asks for a path to some file
>>> >> > from
>>> >> > the
>>> >> > user, which types that path. Now you need to:
>>> >> >
>>> >> > 1. Discover whether you are on a Unix, Windows, or whatever;
>>> >> > 2. Depending on where you are, call the appropriate conversion to
>>> >> > URL.
>>> >> > 3. Use that URL to open the file.
>>> >> >
>>> >> > That's not even scalable, as you have to hard code every possible
>>> >> > variante
>>> >> > on path naming.
>>> >> >
>>> >> > But the fact is that the user _knows_ what kind of Path the operating
>>> >> > system
>>> >> > he is _using_ accepts.
>>> >> >
>>> >> > Now extend that to parameters passed on the command line, environment
>>> >> > variables, configuration files, etc.
>>> >> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>>> >> > <kev.lee.wright@googlemail.com> wrote:
>>> >> >>
>>> >> >> I'd love to have an underlying representation that mirrors how
>>> >> >> filesystems actually behave, taking a domain-driven approach.
>>> >> >> Then layer any simplifications we need over the top of that.
>>> >> >>
>>> >> >> Whatever we do, the filesystem is what it is, so we'll always have
>>> >> >> to
>>> >> >> simplify at some point between the FS and user code.
>>> >> >> It just feels right to have that intermediate "less simple, but
>>> >> >> correct" layer between the two, so we can better handle the
>>> >> >> non-trivial use cases.
>>> >> >>
>>> >> >>
>>> >> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko <a@gaydenko.com>
>>> >> >> wrote:
>>> >> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>>> >> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>>> >> >> >> <dcsobral@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >> > Guys, stand back. Take a deep breath.
>>> >> >> >> >
>>> >> >> >> > A file/directory API has a main goal, one responsible for 99%+
>>> >> >> >> > of
>>> >> >> >> > its
>>> >> >> >> > expected usage: dealing with files and directories on Windows
>>> >> >> >> > and
>>> >> >> >> > Unix.
>>> >> >> >> > The fact that there are many variations on the theme on
>>> >> >> >> > uncommon operating systems is of very, very little relevant. In
>>> >> >> >> > fact,
>>> >> >> >> > I'm
>>> >> >> >> > much more concerned about volumes on big iron than with other
>>> >> >> >> > unusual
>>> >> >> >> > things talked about here.
>>> >> >> >> >
>>> >> >> >> > The use case is to open and close files, read, write, position
>>> >> >> >> > and
>>> >> >> >> > truncate them. List files in a directory. Create, delete,
>>> >> >> >> > rename
>>> >> >> >> > and
>>> >> >> >> > move
>>> >> >> >> > files and directories. Identify whether you have permissions
>>> >> >> >> > for
>>> >> >> >> > doing
>>> >> >> >> > it, and identify if something can be treated as a file or as a
>>> >> >> >> > directory.
>>> >> >> >> > And, in all that, use user input to identify them, and display
>>> >> >> >> > them
>>> >> >> >> > back
>>> >> >> >> > to the user, in a system-dependent manner (just like locales).
>>> >> >> >> >
>>> >> >> >> > So, whatever you do, make sure THAT is easy. If necessary, make
>>> >> >> >> > the
>>> >> >> >> > rest
>>> >> >> >> > complex.
>>> >> >> >>
>>> >> >> >> +1.
>>> >> >> >>
>>> >> >> >> Quoting Alan Kay: ``Simple things should be simple, complex
>>> >> >> >> things
>>> >> >> >> should be possible.''
>>> >> >> >>
>>> >> >> >> Cheers
>>> >> >> >>
>>> >> >> >>  -- Martin
>>> >> >> >
>>> >> >> > He-he... :-) A month and half ago I have cried wrt Scala IO (the
>>> >> >> > opinion
>>> >> >> > was
>>> >> >> > not shared by somebody):
>>> >> >> >
>>> >> >> > "Abstractions are for pleasing dealing with concrete things,
>>> >> >> > rather
>>> >> >> > things
>>> >> >> > exist to express beautyful abstractions."
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Daniel C. Sobral
>>> >> >
>>> >> > Something I learned in academia: there are three kinds of academic
>>> >> > reviews:
>>> >> > review by name, review by reference and review by value.
>>> >> >
>>> >
>>> >
>>
>>
>



--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
Google Wave: ricky.clarkson@googlewave.com

Agreed, it definitely does cause problems and we'd be wise to
normalise any paths to use \ before windows sees them
(unless in file:// form)

I still think there's a valid argument for consistently using / in
relative paths though, then flip to \ when appending a relative path
to a windows absolute path, or when handing a relative path windows.

On Thu, Oct 22, 2009 at 2:48 PM, Sébastien Lorion
wrote:
> Yes, the Windows API supports it (mainly because of Unix Services), but it
> is very seldom used in typical Windows code and a lot of
> applications/libraries will break if they receive an unix-style relative
> path.
>
> Sébastien
>
> On Thu, Oct 22, 2009 at 09:41, Ricky Clarkson
> wrote:
>>
>> Windows will, yes, but there are cases where it won't.  Really basic
>> cases, e.g., dir /
>>
>> 2009/10/22 Kevin Wright :
>> > On Thu, Oct 22, 2009 at 2:01 PM, Sébastien Lorion
>> > wrote:
>> >> Java is abstracting them, on Windows, it's really "..\..\". In .NET, it
>> >> is
>> >> using a readonly field named System.IO.Path.DirectorySeparatorChar,
>> >> which
>> >> changes according to the platform. On Windows, it is "\".
>> >
>> > Windows will also accept / used on the command line (think that one
>> > first came in with windows NT, when MS were keen on getting people to
>> > migrate from unix)
>> >
>> > So this isn't just a Java abstraction, although I have no doubt lots
>> > of code exists that normalises paths to the usual windows convention
>> >
>> >
>> >> Sébastien
>> >> On Thu, Oct 22, 2009 at 04:55, Kevin Wright
>> >>
>> >> wrote:
>> >>>
>> >>> On Wed, Oct 21, 2009 at 8:05 PM, Sébastien Lorion
>> >>> wrote:
>> >>> > On Windows, people almost always use the relative path of the form
>> >>> > "..\..\"
>> >>> > for local files, not "../../" (which only works with file://).
>> >>>
>> >>> This doesn't match my experience, almost every config file I write for
>> >>> java apps uses / as a separator, regardless of operating system.
>> >>> (most of these apps run on both windows and linux anyway)
>> >>>
>> >>> Anything typed in by end users should use \ though, and anything via
>> >>> by a gui almost certainly will.
>> >>>
>> >>> It's also possible that some relative paths could be pre-defined and
>> >>> then resolved at runtime (i.e. by making relative to the app
>> >>> directory), this means that the same relative path could be used on
>> >>> different OSs - which is why I think relative and absolute paths
>> >>> should be treated as different beasts.
>> >>>
>> >>> > I would separate concern between manipulating paths (as URI) and
>> >>> > converting
>> >>> > them to specific representations. Something like Path composes an
>> >>> > IPathConverter which allows to convert from/to OS specific
>> >>> > representations.
>> >>> > It could also be done in a more functional way with converter
>> >>> > function
>> >>> > instead of interface.
>> >>> > Sébastien
>> >>> > On Wed, Oct 21, 2009 at 08:51, Kevin Wright
>> >>> >
>> >>> > wrote:
>> >>> >>
>> >>> >> I think we can be smarter than that
>> >>> >>
>> >>> >> starting with file:// or another protocol prefix = pure URL
>> >>> >> starting with c:, d:, e:, ... = windows
>> >>> >> starting \\ = windows
>> >>> >> using only \ = windows
>> >>> >> starting / = unix
>> >>> >> using only / = windows
>> >>> >>
>> >>> >> The tricky part is relative paths, where people will frequently use
>> >>> >> /
>> >>> >> regardless of the OS
>> >>> >> It's also makes no sense to have an OS-specific relative path
>> >>> >>
>> >>> >> So... perhaps there should be a type separation between absolute
>> >>> >> and
>> >>> >> relative path forms.  I can see several benefits to that approach.
>> >>> >>
>> >>> >>
>> >>> >> Maybe something like this would work as a type hierarchy:
>> >>> >>
>> >>> >> Path
>> >>> >> - RelativePath
>> >>> >> - AbsolutePath
>> >>> >> - - UrlPath
>> >>> >> - - WindowsPath
>> >>> >> - - UnixPath
>> >>> >>
>> >>> >>
>> >>> >> On Wed, Oct 21, 2009 at 1:31 PM, Daniel Sobral
>> >>> >> wrote:
>> >>> >> > I agree. But not how using URL to handle Paths, as shown, go...
>> >>> >> > You
>> >>> >> > have
>> >>> >> > a
>> >>> >> > program running somewhere. The program asks for a path to some
>> >>> >> > file
>> >>> >> > from
>> >>> >> > the
>> >>> >> > user, which types that path. Now you need to:
>> >>> >> >
>> >>> >> > 1. Discover whether you are on a Unix, Windows, or whatever;
>> >>> >> > 2. Depending on where you are, call the appropriate conversion to
>> >>> >> > URL.
>> >>> >> > 3. Use that URL to open the file.
>> >>> >> >
>> >>> >> > That's not even scalable, as you have to hard code every possible
>> >>> >> > variante
>> >>> >> > on path naming.
>> >>> >> >
>> >>> >> > But the fact is that the user _knows_ what kind of Path the
>> >>> >> > operating
>> >>> >> > system
>> >>> >> > he is _using_ accepts.
>> >>> >> >
>> >>> >> > Now extend that to parameters passed on the command line,
>> >>> >> > environment
>> >>> >> > variables, configuration files, etc.
>> >>> >> > On Wed, Oct 21, 2009 at 7:31 AM, Kevin Wright
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> I'd love to have an underlying representation that mirrors how
>> >>> >> >> filesystems actually behave, taking a domain-driven approach.
>> >>> >> >> Then layer any simplifications we need over the top of that.
>> >>> >> >>
>> >>> >> >> Whatever we do, the filesystem is what it is, so we'll always
>> >>> >> >> have
>> >>> >> >> to
>> >>> >> >> simplify at some point between the FS and user code.
>> >>> >> >> It just feels right to have that intermediate "less simple, but
>> >>> >> >> correct" layer between the two, so we can better handle the
>> >>> >> >> non-trivial use cases.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Wed, Oct 21, 2009 at 10:12 AM, Andrew Gaydenko
>> >>> >> >>
>> >>> >> >> wrote:
>> >>> >> >> > On Wednesday 21 October 2009 12:28:04 martin odersky wrote:
>> >>> >> >> >> On Tue, Oct 20, 2009 at 4:52 PM, Daniel Sobral
>> >>> >> >> >>
>> >>> >> >> >> wrote:
>> >>> >> >> >> > Guys, stand back. Take a deep breath.
>> >>> >> >> >> >
>> >>> >> >> >> > A file/directory API has a main goal, one responsible for
>> >>> >> >> >> > 99%+
>> >>> >> >> >> > of
>> >>> >> >> >> > its
>> >>> >> >> >> > expected usage: dealing with files and directories on
>> >>> >> >> >> > Windows
>> >>> >> >> >> > and
>> >>> >> >> >> > Unix.
>> >>> >> >> >> > The fact that there are many variations on the theme on
>> >>> >> >> >> > uncommon operating systems is of very, very little
>> >>> >> >> >> > relevant. In
>> >>> >> >> >> > fact,
>> >>> >> >> >> > I'm
>> >>> >> >> >> > much more concerned about volumes on big iron than with
>> >>> >> >> >> > other
>> >>> >> >> >> > unusual
>> >>> >> >> >> > things talked about here.
>> >>> >> >> >> >
>> >>> >> >> >> > The use case is to open and close files, read, write,
>> >>> >> >> >> > position
>> >>> >> >> >> > and
>> >>> >> >> >> > truncate them. List files in a directory. Create, delete,
>> >>> >> >> >> > rename
>> >>> >> >> >> > and
>> >>> >> >> >> > move
>> >>> >> >> >> > files and directories. Identify whether you have
>> >>> >> >> >> > permissions
>> >>> >> >> >> > for
>> >>> >> >> >> > doing
>> >>> >> >> >> > it, and identify if something can be treated as a file or
>> >>> >> >> >> > as a
>> >>> >> >> >> > directory.
>> >>> >> >> >> > And, in all that, use user input to identify them, and
>> >>> >> >> >> > display
>> >>> >> >> >> > them
>> >>> >> >> >> > back
>> >>> >> >> >> > to the user, in a system-dependent manner (just like
>> >>> >> >> >> > locales).
>> >>> >> >> >> >
>> >>> >> >> >> > So, whatever you do, make sure THAT is easy. If necessary,
>> >>> >> >> >> > make
>> >>> >> >> >> > the
>> >>> >> >> >> > rest
>> >>> >> >> >> > complex.
>> >>> >> >> >>
>> >>> >> >> >> +1.
>> >>> >> >> >>
>> >>> >> >> >> Quoting Alan Kay: ``Simple things should be simple, complex
>> >>> >> >> >> things
>> >>> >> >> >> should be possible.''
>> >>> >> >> >>
>> >>> >> >> >> Cheers
>> >>> >> >> >>
>> >>> >> >> >>  -- Martin
>> >>> >> >> >
>> >>> >> >> > He-he... :-) A month and half ago I have cried wrt Scala IO
>> >>> >> >> > (the
>> >>> >> >> > opinion
>> >>> >> >> > was
>> >>> >> >> > not shared by somebody):
>> >>> >> >> >
>> >>> >> >> > "Abstractions are for pleasing dealing with concrete things,
>> >>> >> >> > rather
>> >>> >> >> > things
>> >>> >> >> > exist to express beautyful abstractions."
>> >>> >> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > --
>> >>> >> > Daniel C. Sobral
>> >>> >> >
>> >>> >> > Something I learned in academia: there are three kinds of
>> >>> >> > academic
>> >>> >> > reviews:
>> >>> >> > review by name, review by reference and review by value.
>> >>> >> >
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky.clarkson@gmail.com
>> Google Wave: ricky.clarkson@googlewave.com
>
>

On Thu, Oct 22, 2009 at 3:02 PM, Kevin Wright
wrote:
> Agreed, it definitely does cause problems and we'd be wise to
> normalise any paths to use \ before windows sees them
> (unless in file:// form)
>
> I still think there's a valid argument for consistently using / in
> relative paths though, then flip to \ when appending a relative path
> to a windows absolute path, or when handing a relative path windows.

Why on earth are we discussing this?

It's *precisely* the kind of thing a Path API should abstract away.

It's *precisely* the kind of thing we should be delegating the
implementation of to NIO2.

http://download.java.net/jdk7/docs/api/java/nio/file/Paths.html

Cheers,

Miles

I can't wait until I have regular internet access.  I can read but writing messages is difficult.  By the time I have a message ready it is out of date :(  4 days left.


Ok a quick email before I am kicked off the internet (I have not time to proof read so forgive me if it is a little rough):

My primary goal is to create a flexible filesystem that can do the simple case well and permit all crazy ideas as well (even if they require a bit more work).  So with this in mind I am following the NIO2 API pretty closely because they have thought out most of those corner cases quite well. 

However I want to experiment with a GenericPath that is guaranteed to work with Windows and Unix style filesystems but not necessarily others.  This will be experimental at first but if found useful we can probably make it part of the official API. 
The idea with GenericPath would be to have one set of rules for defining the path and there would be converters to the supported filesystems.  There will not be a plugin system for it at first but perhaps in time we can add a SPI for it.

It is not the highest priority because using the normal Path factory methods make it quite easy to construct and manipulate paths already. 

I am still doing the rough draft of the API but when that is complete I will make a large page of samples so we can criticize and work out the kinks of the API.


Jesse

On Thu, Oct 22, 2009 at 7:13 AM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Oct 22, 2009 at 3:02 PM, Kevin Wright
<kev.lee.wright@googlemail.com> wrote:
> Agreed, it definitely does cause problems and we'd be wise to
> normalise any paths to use \ before windows sees them
> (unless in file:// form)
>
> I still think there's a valid argument for consistently using / in
> relative paths though, then flip to \ when appending a relative path
> to a windows absolute path, or when handing a relative path windows.

Why on earth are we discussing this?

It's *precisely* the kind of thing a Path API should abstract away.

It's *precisely* the kind of thing we should be delegating the
implementation of to NIO2.

 http://download.java.net/jdk7/docs/api/java/nio/file/Paths.html

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin